6 ms·

Cool project (and written in my favourite language), but I really hate how there's no space at the end of your prompt.

by GrayShade 5y ago

flusteredBias 5y ago
Love the idea! Already opened the issue and will merge a PR before the next release.
- GrayShade 5y ago
  Ah, I didn't mean a newline at the end of the output. Just a space after your shell prompt ($), see e.g. `user@~/code/data$cat` in https://github.com/alexhallam/tv/blob/main/img/column_v_tv2.png https://github.com/alexhallam/tv/blob/main/img/column_v_tv2.....
  - flusteredBias 5y ago
    lol. Got it.
- deleted 5y ago
  [deleted]
stavros 5y ago
I have to agree, I felt dirty watching the recording. The project looks great, though.
BiteCode_dev 5y ago
It feels like when somebody opens a ( but doesn't close it.
- hoosieree 5y ago
  )
  - BiteCode_dev 5y ago
    There is such a big latency in HN for self closing parenthesis.
lambic 5y ago
And the use of cat on a single file..
- netcraft 5y ago
  I don't understand your comment - could you expand on it?
  - ComputerGuru 5y ago
    cat just regurgitates the contents of the file, but the resulting piped fd is non-seekable. Since almost every command that can operate on a file from stdin can also operate on the file by name/path, at best this is just a needless invocation of a process (i.e. `tv foo.csv` should have been used instead of `cat foo.csv | tv`) - if the app in question can't handle paths, then you can have the shell pipe the file into it instead (e.g. `tv < foo.csv`). At worst, the recipient program would need to buffer the entire contents of the input if it needs to perform non-sequential operations on the source data - this is the case with things like `tac` that need to seek to the end of the input (see https://github.com/neosmart/tac https://github.com/neosmart/tac for how `cat foo | tac` requires buffering but both `tac foo` and even `tac < foo` don't).
    - netcraft 5y ago
      thank you! I knew some of that but learned a lot too.
      - mthoms 5y ago
        Google the phrase "useless use of cat". To some, it's a faux-pas. Personally, I like the aesthetics of cat for my own scripts. It follows the "pipe flowing" idiom better. There are performance reasons why "useless cat" should be avoided though. So avoid it where performance is important (or when some other hardcore CLI jockey is going to see your code :))
        hibbelig 5y ago

Cool project (and written in my favourite language), but I really hate how there's no space at the end of your prompt.

flusteredBias 5y ago

Love the idea! Already opened the issue and will merge a PR before the next release.

GrayShade 5y ago
Ah, I didn't mean a newline at the end of the output. Just a space after your shell prompt ($), see e.g. `user@~/code/data$cat` in https://github.com/alexhallam/tv/blob/main/img/column_v_tv2.png https://github.com/alexhallam/tv/blob/main/img/column_v_tv2.....
- flusteredBias 5y ago
  lol. Got it.
deleted 5y ago
[deleted]

stavros 5y ago

I have to agree, I felt dirty watching the recording. The project looks great, though.

BiteCode_dev 5y ago

It feels like when somebody opens a ( but doesn't close it.

hoosieree 5y ago
)
- BiteCode_dev 5y ago
  There is such a big latency in HN for self closing parenthesis.

lambic 5y ago

And the use of cat on a single file..

netcraft 5y ago
I don't understand your comment - could you expand on it?
- ComputerGuru 5y ago
  cat just regurgitates the contents of the file, but the resulting piped fd is non-seekable. Since almost every command that can operate on a file from stdin can also operate on the file by name/path, at best this is just a needless invocation of a process (i.e. `tv foo.csv` should have been used instead of `cat foo.csv | tv`) - if the app in question can't handle paths, then you can have the shell pipe the file into it instead (e.g. `tv < foo.csv`). At worst, the recipient program would need to buffer the entire contents of the input if it needs to perform non-sequential operations on the source data - this is the case with things like `tac` that need to seek to the end of the input (see https://github.com/neosmart/tac https://github.com/neosmart/tac for how `cat foo | tac` requires buffering but both `tac foo` and even `tac < foo` don't).
  - netcraft 5y ago
    thank you! I knew some of that but learned a lot too.
    - mthoms 5y ago
      Google the phrase "useless use of cat". To some, it's a faux-pas. Personally, I like the aesthetics of cat for my own scripts. It follows the "pipe flowing" idiom better. There are performance reasons why "useless cat" should be avoided though. So avoid it where performance is important (or when some other hardcore CLI jockey is going to see your code :))
      - hibbelig 5y ago