7 ms·

I'm suprised you can't think of problems you currently have with shells. Here is a few of mine: * Once I've started a program, and easy way of sending it to th

I'm suprised you can't think of problems you currently have with shells. Here is a few of mine: * Once I've started a program, and easy way of sending it to the background if it is taking a while, which sends it's output to some buffer I can refer to later, rather than continuing to spew it all over the screen. * While we are at it, stop spewing the output of multiple programs over the screen, under any circumstances. * Have some simple, easy to follow rules which let me work on files that have spaces in their names, without having to remember the various commands with various special cases (like -print0).

MereInterest 11y ago
For the first two issues, I use tmux. If something is long-running, I open a new shell to continue working. If I want to run multiple related commands, I can open many shells and have tmux send my keystrokes to all of them.
ZenoArrow 11y ago
Those can all be seen as tweaks to existing shells. With regards to... "* Have some simple, easy to follow rules which let me work on files that have spaces in their names, without having to remember the various commands with various special cases (like -print0)." I'm not sure I understand what's hard about files with spaces in their names. I'd say it's easy enough to work with such filepaths by using tab autocomplete when using the shell interactively, and quote marks when writing shell scripts. Can you give an example of where these approaches wouldn't work?
- joosters 11y ago
  When you pipe the output of one command into another, e.g 'ls | wc' (obviously a dumb example), the second command will split the filenames on spaces and so will not run properly. The workarounds for this all involve nasty extra parameters for different commands (e.g. the -print0 example)
  - txutxu 11y ago
    ls is not bash wc is not bash And that is a discouraged way to count files in shell script. Still, simply adding -l to ls, could handle spaces correctly (the files count) I insist, spaces are not your enemy, there are much more weird file names for a shell. Shell can handle spaces if used properly.
    - dfcowell 11y ago
      That there are worse things that exist is no reason not to pluck the low hanging fruit. I see this attitude on HN a lot. Spaces are probably the 80 in the 80/20 rule here. Why not address them?
      - txutxu 11y ago
        Please give a single example in shell about spaces, that has not been already addressed. From where do your get that rule?
        tomsmeding 11y ago
        It's the pareto principle. In this case he means "20% of the problems account for 80% of the trouble" -- albeit somwhat strangely worded.
        txutxu 11y ago
        Thanks I did know about the theory. My question was more about where are the numbers coming from? I write shell daily, and that are not my numbers regarding "spaces on filenames issues", sorry.
    - txutxu 11y ago
      Not sure on why this comment got down-voted. If it's because I did not explain how to do that, there is howto do it: http://mywiki.wooledge.org/BashFAQ/004 If it's because the comment on the given example... $ touch file1 $ ls -l | wc -l 1 $ touch "file 2" $ ls -l | wc -l 2 ... (?) If we were talking about "new lines in file names", or "dashes at the beginning of file names", or code injection through file names, then we could be talking of more complex solutions. But the space issues in shell are simple, and have known solutions. If you're a daily user or you're not at learning stage, spaces don't turn to be a issue.
voidz 11y ago
Thanks to tmux, I don't have a problem with multiple interactive commands and their outputs. If I need to do something new, I open another shell on a new pane. Not that other solutions aren't welcome, but this works for me. If I don't want output at all, the &>/dev/null output redirection works, or file descriptor redirection, for which zsh has useful methods. Spaces in filenames are easily solved by quoting filenames or variables. Again, zsh provides a myriad of ways to make this a trivial issue. My main point was to argue what qualifies as to being called 'shell'.
- Bjartr 11y ago
  One of the problems tmux and friends don't solve that a "smarter" underlying system might add is the ability to make the choice to detach a process or redirect its output after it's already begun running. For example, I specifically have had on many occasions started something and then later wished I'd previously started screen. While, "gain the knowledge to better configure your environment to start" is a valid response, equally valid is a desire for a more flexible default environment in general.
  - dmytrish 11y ago
    "Detach during running" is a problem solved from the beginning of shells: just suspend a foreground command with C-z and type `bg` to wake it up in the background. Output redirection seems to be a valid point, though.
txutxu 11y ago
issue 1) sounds like you miss nohup, sreen or tmux in front of that long running program. issue 2) usually I don't have one terminal session with multiple programs doing output at the same time, this solves this issue. Just use a new xterm, a new terminal tab, a new screen tab for programs that are going to produce output and stay running. issue 3) I think you refer to files with other special characters, because spaces on filenames do not need -print0 at all, simply proper quoting in the code will do. Regarding issue 3, there is a lot of caveats when coding shell; even file names starting with a dash (-) which are interpreted as options by tools external to the shell (which fortunately support a double dash (--) to stop processing parameters).
- ashitlerferad 11y ago
  This is the canonical writeup about argument injection vulnerabilities: http://www.defensecode.com/public/DefenseCode_Unix_WildCards_Gone_Wild.txt http://www.defensecode.com/public/DefenseCode_Unix_WildCards...
- hibbelig 11y ago
  The point of issue 1 is that sometimes you don't know that the program will run for a long time. So a way to send a program into the background while it is already running, would be nice.
  - txutxu 11y ago
    'Ctrl + z', 'bg' and 'fg' are for that.
    - CJefferson 11y ago
      Except, now you are back to my original problem -- the output of the program will continue to spew all over my terminal.
      - txutxu 11y ago
        Well, if you work always in tmux/screen (a recommended practice for operations, that I did import to my daily shell activity) you don't need job control. When there is a "surprisingly slow" command, then just press the shortcut for a new screen session. Will get alerted in the status bar when the slow command finishes. Output of each command will be in it's own screen session (not mixed). That Ctrl + z response was no for issue1, but for the wishes of the second sentence of @hibbelig.
dumbguy 11y ago
Just use tmux. It'll take a day to figure out, and then all your problems go away. Well, save the spaces, that's never going to happen.
- chriswarbo 11y ago
  > all your problems go away. Well, save the spaces, that's never going to happen. Spaces in filenames are fine. The only strange thing is that, as it turns out, shells have this hidden easter-egg/anti-feature where you can actually leave out the quotes around filenames under certain, special edge-case scenarios. One of those is when the filename contains no ampersands, quotation marks, asterisks, dollar-signs, parentheses, backslashes, newlines, or, you guessed it, spaces! In fact, this special "no quote mode" also contains another special, embedded mode where you can still use those characters, but put backslashes before them! Since this layering of tricks leads to funky, confusing-looking commands, it's obviously much better to just stick with the regular mode of quoting everything. Of course, the above is quite tongue-in-cheek, but its the mental-mode I specifically try to adopt: "occasionally, you might get away with leaving out the quotes"; compared to the seemingly more common "you need to add quotes in these cases". Still, this doesn't eliminate the problem of single-quotes in filenames never going away! Whilst it only requires one character code to be escaped, it's still accomplished in a pretty funky way: "'" becomes "'\''"; we first close the string, then use a backslash to write a literal "'", then we start a new string ;)
  - Tiksi 11y ago
    You could use a shell that magically handles all the escaping for you either while typing/pasting for some programs (curl, grep etc) when not in quotes and tab completes with a selector so you don't have to think about spaces, special chars, etc: http://paste.click/VfUUWv http://paste.click/VfUUWv
Intermernet 11y ago
I'd personally like a way to redirect the output of a running process (either `bg`d or `disown`ed) to a log file. The only way I've come across are horrible hacks using gdb[1] or strace. This should be easier. Anyone know of any better ways? I'd like to be able to do something like `proclog <pid> <stdout output file> <stderr output file>`. [1]: http://stackoverflow.com/questions/593724/redirect-stderr-stdout-of-a-process-after-its-been-started-using-command-lin http://stackoverflow.com/questions/593724/redirect-stderr-st...
- tyingq 11y ago
  There's this: http://www.isi.edu/~yuri/dupx/dupx_man.html http://www.isi.edu/~yuri/dupx/dupx_man.html Still uses gdb under the covers, but presents a front end close to what you are asking for.

MereInterest 11y ago

For the first two issues, I use tmux. If something is long-running, I open a new shell to continue working. If I want to run multiple related commands, I can open many shells and have tmux send my keystrokes to all of them.

ZenoArrow 11y ago

Those can all be seen as tweaks to existing shells. With regards to... "* Have some simple, easy to follow rules which let me work on files that have spaces in their names, without having to remember the various commands with various special cases (like -print0)." I'm not sure I understand what's hard about files with spaces in their names. I'd say it's easy enough to work with such filepaths by using tab autocomplete when using the shell interactively, and quote marks when writing shell scripts. Can you give an example of where these approaches wouldn't work?

joosters 11y ago
When you pipe the output of one command into another, e.g 'ls | wc' (obviously a dumb example), the second command will split the filenames on spaces and so will not run properly. The workarounds for this all involve nasty extra parameters for different commands (e.g. the -print0 example)
- txutxu 11y ago
  ls is not bash wc is not bash And that is a discouraged way to count files in shell script. Still, simply adding -l to ls, could handle spaces correctly (the files count) I insist, spaces are not your enemy, there are much more weird file names for a shell. Shell can handle spaces if used properly.
  - dfcowell 11y ago
    That there are worse things that exist is no reason not to pluck the low hanging fruit. I see this attitude on HN a lot. Spaces are probably the 80 in the 80/20 rule here. Why not address them?
    - txutxu 11y ago
      Please give a single example in shell about spaces, that has not been already addressed. From where do your get that rule?
      - tomsmeding 11y ago
        It's the pareto principle. In this case he means "20% of the problems account for 80% of the trouble" -- albeit somwhat strangely worded.
        txutxu 11y ago
        Thanks I did know about the theory. My question was more about where are the numbers coming from? I write shell daily, and that are not my numbers regarding "spaces on filenames issues", sorry.
  - txutxu 11y ago
    Not sure on why this comment got down-voted. If it's because I did not explain how to do that, there is howto do it: http://mywiki.wooledge.org/BashFAQ/004 If it's because the comment on the given example... $ touch file1 $ ls -l | wc -l 1 $ touch "file 2" $ ls -l | wc -l 2 ... (?) If we were talking about "new lines in file names", or "dashes at the beginning of file names", or code injection through file names, then we could be talking of more complex solutions. But the space issues in shell are simple, and have known solutions. If you're a daily user or you're not at learning stage, spaces don't turn to be a issue.

voidz 11y ago

Thanks to tmux, I don't have a problem with multiple interactive commands and their outputs. If I need to do something new, I open another shell on a new pane. Not that other solutions aren't welcome, but this works for me. If I don't want output at all, the &>/dev/null output redirection works, or file descriptor redirection, for which zsh has useful methods. Spaces in filenames are easily solved by quoting filenames or variables. Again, zsh provides a myriad of ways to make this a trivial issue. My main point was to argue what qualifies as to being called 'shell'.

Bjartr 11y ago
One of the problems tmux and friends don't solve that a "smarter" underlying system might add is the ability to make the choice to detach a process or redirect its output after it's already begun running. For example, I specifically have had on many occasions started something and then later wished I'd previously started screen. While, "gain the knowledge to better configure your environment to start" is a valid response, equally valid is a desire for a more flexible default environment in general.
- dmytrish 11y ago
  "Detach during running" is a problem solved from the beginning of shells: just suspend a foreground command with C-z and type `bg` to wake it up in the background. Output redirection seems to be a valid point, though.

txutxu 11y ago

issue 1) sounds like you miss nohup, sreen or tmux in front of that long running program. issue 2) usually I don't have one terminal session with multiple programs doing output at the same time, this solves this issue. Just use a new xterm, a new terminal tab, a new screen tab for programs that are going to produce output and stay running. issue 3) I think you refer to files with other special characters, because spaces on filenames do not need -print0 at all, simply proper quoting in the code will do. Regarding issue 3, there is a lot of caveats when coding shell; even file names starting with a dash (-) which are interpreted as options by tools external to the shell (which fortunately support a double dash (--) to stop processing parameters).

ashitlerferad 11y ago
This is the canonical writeup about argument injection vulnerabilities: http://www.defensecode.com/public/DefenseCode_Unix_WildCards_Gone_Wild.txt http://www.defensecode.com/public/DefenseCode_Unix_WildCards...
hibbelig 11y ago
The point of issue 1 is that sometimes you don't know that the program will run for a long time. So a way to send a program into the background while it is already running, would be nice.
- txutxu 11y ago
  'Ctrl + z', 'bg' and 'fg' are for that.
  - CJefferson 11y ago
    Except, now you are back to my original problem -- the output of the program will continue to spew all over my terminal.
    - txutxu 11y ago
      Well, if you work always in tmux/screen (a recommended practice for operations, that I did import to my daily shell activity) you don't need job control. When there is a "surprisingly slow" command, then just press the shortcut for a new screen session. Will get alerted in the status bar when the slow command finishes. Output of each command will be in it's own screen session (not mixed). That Ctrl + z response was no for issue1, but for the wishes of the second sentence of @hibbelig.

dumbguy 11y ago

Just use tmux. It'll take a day to figure out, and then all your problems go away. Well, save the spaces, that's never going to happen.

chriswarbo 11y ago
> all your problems go away. Well, save the spaces, that's never going to happen. Spaces in filenames are fine. The only strange thing is that, as it turns out, shells have this hidden easter-egg/anti-feature where you can actually leave out the quotes around filenames under certain, special edge-case scenarios. One of those is when the filename contains no ampersands, quotation marks, asterisks, dollar-signs, parentheses, backslashes, newlines, or, you guessed it, spaces! In fact, this special "no quote mode" also contains another special, embedded mode where you can still use those characters, but put backslashes before them! Since this layering of tricks leads to funky, confusing-looking commands, it's obviously much better to just stick with the regular mode of quoting everything. Of course, the above is quite tongue-in-cheek, but its the mental-mode I specifically try to adopt: "occasionally, you might get away with leaving out the quotes"; compared to the seemingly more common "you need to add quotes in these cases". Still, this doesn't eliminate the problem of single-quotes in filenames never going away! Whilst it only requires one character code to be escaped, it's still accomplished in a pretty funky way: "'" becomes "'\''"; we first close the string, then use a backslash to write a literal "'", then we start a new string ;)
- Tiksi 11y ago
  You could use a shell that magically handles all the escaping for you either while typing/pasting for some programs (curl, grep etc) when not in quotes and tab completes with a selector so you don't have to think about spaces, special chars, etc: http://paste.click/VfUUWv http://paste.click/VfUUWv

Intermernet 11y ago

I'd personally like a way to redirect the output of a running process (either `bg`d or `disown`ed) to a log file. The only way I've come across are horrible hacks using gdb[1] or strace. This should be easier. Anyone know of any better ways? I'd like to be able to do something like `proclog <pid> <stdout output file> <stderr output file>`. [1]: http://stackoverflow.com/questions/593724/redirect-stderr-stdout-of-a-process-after-its-been-started-using-command-lin http://stackoverflow.com/questions/593724/redirect-stderr-st...

tyingq 11y ago
There's this: http://www.isi.edu/~yuri/dupx/dupx_man.html http://www.isi.edu/~yuri/dupx/dupx_man.html Still uses gdb under the covers, but presents a front end close to what you are asking for.