Timeline for Execute bash commands one at a time
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 16 at 14:10 | vote | accept | Mike | ||
| Oct 15 at 12:27 | comment | added | Ed Morton |
Please edit your question to provide a truly representative "list of commands" you want to operate on. Make sure to include the worst-case scenarios, e.g. multi-line "commands" and commands that involve complicated mixes of single/double quoting, use of variables, spawning sub-processes, etc. not just sunny day cases like mv file1 file2.
|
|
| Oct 13 at 16:15 | comment | added | Barmar |
How do you want to handle if and while blocks? Should the entire block be considered a single command, or do you want to single-step the individual commands in the body?
|
|
| Oct 13 at 14:40 | answer | added | Marcus Müller | timeline score: 0 | |
| Oct 13 at 11:18 | answer | added | ilkkachu | timeline score: 3 | |
| Oct 12 at 15:17 | comment | added | markp-fuso |
you'll also need to consider the 'complexity' of the command; dynamically running date vs printf "%s %s\n" 1 2 vs echo "scale=2;1+3" | bc requires different approaches; also need to know if a command relies on the result of a previous command, eg, x=3 and then echo "$x" (question being do the commands need to be run in the same shell or will separate subshells be ok); error handling (capturing return codes vs capturing-and-testing stdout/stderr) adds more complexity to the mix (eg, what to do with invalid_command vs invalid_command > std.out 2>std.err?)
|
|
| Oct 12 at 10:39 | comment | added | Hannu | There is always a threshold when you're trying something new; NOT having something similar to these to read means you're struggling on your own. By saying to browse I indicate that you do not HAVE TO read all of it. Whether they suit you personally depends on your prior experience, not easy to catch a total newbie. | |
| Oct 12 at 10:31 | comment | added | Marcus Müller | @Hannu no criticism, just an honest question: are the guides at tldp the thing you would have wanted to read as a beginner? I didn't learn about them before long after I've had amassed experience with shells, and quite honestly, they are didactically not what I would have needed when I was new to bash. But I'm just me, not everyone. | |
| Oct 12 at 9:49 | comment | added | Paul_Pedant | Consider how you would proceed if you actually do find an error at some stage. You will want to fix the issue, and then restart the list of commands partway through. I would probably list the commands in a file, and then have a control script that works through that file from the top, showing every command before it is executed, and offering options to quit, skip, or run one command. You could also add to the list an echo noting the checks you need to do at each point. It is way too easy to lose the thread during this kind of activity unless you have reminders. | |
| Oct 12 at 9:03 | comment | added | Hannu | To get to grips with things like the above and what other options you have in bash, check the Bash guides at www.tldp.org - already browsing through them will have you know more than currently. | |
| Oct 11 at 23:02 | comment | added | Mike | @MarcusMüller Yes, they're simple commands. Almost all will be "mv file1 file2" commands. | |
| Oct 11 at 22:59 | comment | added | Marcus Müller |
could you tell us what the most complex bash script that you want to run is? Is it really just one command after the other, as your choice of words "a list of bash commands" suggests? or might it involve calling bash functions (and would you want that function to be one "command" or "step" through the function's contents as well? how deeply?) or even loops like for f in *.mp3; do id3tag "$f"; done?
|
|
| Oct 11 at 22:54 | answer | added | Gilles Quénot | timeline score: 0 | |
| Oct 11 at 22:48 | history | asked | Mike | CC BY-SA 4.0 |