4 ms·

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 prog

by 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.
      - hibbelig 11y ago
        I meant to include the part of capturing the output -- the part that Ctrl+Z does not do. Opening a new screen/tmux session is a cool idea, but the new session doesn't inherit the state from the already running one, I guess. (At least in screen, not sure about tmux.) By "state" I mean the shell history, the current working directory, the (environment) variables. Also, say that long running command runs five minutes, and after one minute you create a new session. Then after four more minutes you now have two sessions, both ready to accept input. Which one do you use to continue working? How do you know which one to close?
        txutxu 11y ago
        My screen respects the current working directory for new sessions. My history is configured to write at every prompt redraw and to don't miss commands. With vanilla history and prompt command settings, history will be separated. But as this is a common problem, and not only with screen, also with multiple xterms and IDE's shells, and... also is a problem that history may miss lines by default... And as it's a common problem, there are settings to fix that, configure the history merge strategy to your taste and do not miss history lines, because you did close a xterm, or you did open a new screen sessions. Curiously, those settings are even documented upstream. Session variables? I expect the ones that could be loaded by login executing bash -l... If I did export something after that, then maybe I simply need to export it again in a new session, but really in 20 years never was in this situation I think... (do not wait to a command, continue with other commands, and need a environment variable not initialized by default between both sessions....). If I was in that situation... was so easy to fix that I don't even remember. Which one to close? the one I prefer randomly, probably by focus, or probably the highest screen id. As history is merged, I can close any or even both.

by txutxu 11y ago

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.
    - hibbelig 11y ago
      I meant to include the part of capturing the output -- the part that Ctrl+Z does not do. Opening a new screen/tmux session is a cool idea, but the new session doesn't inherit the state from the already running one, I guess. (At least in screen, not sure about tmux.) By "state" I mean the shell history, the current working directory, the (environment) variables. Also, say that long running command runs five minutes, and after one minute you create a new session. Then after four more minutes you now have two sessions, both ready to accept input. Which one do you use to continue working? How do you know which one to close?
      - txutxu 11y ago
        My screen respects the current working directory for new sessions. My history is configured to write at every prompt redraw and to don't miss commands. With vanilla history and prompt command settings, history will be separated. But as this is a common problem, and not only with screen, also with multiple xterms and IDE's shells, and... also is a problem that history may miss lines by default... And as it's a common problem, there are settings to fix that, configure the history merge strategy to your taste and do not miss history lines, because you did close a xterm, or you did open a new screen sessions. Curiously, those settings are even documented upstream. Session variables? I expect the ones that could be loaded by login executing bash -l... If I did export something after that, then maybe I simply need to export it again in a new session, but really in 20 years never was in this situation I think... (do not wait to a command, continue with other commands, and need a environment variable not initialized by default between both sessions....). If I was in that situation... was so easy to fix that I don't even remember. Which one to close? the one I prefer randomly, probably by focus, or probably the highest screen id. As history is merged, I can close any or even both.