3 ms·
Usually true but not always. Calling a for loop iterator "index" instead of "i" just adds unnecessary noise, for example. I think "set -e" in bash should becom
by stormbrew 13y ago
Usually true but not always. Calling a for loop iterator "index" instead of "i" just adds unnecessary noise, for example.
I think "set -e" in bash should become common on the same level, it's pretty rare that you really want a script to continue after an unguarded error return.
- dsfadadsffd 13y agoYes, and you can always set +e if you need to undo it.
- stormbrew 13y agoI do, however, really despise that you use - to turn these things on and + to turn them off. Without the + you just think of it as being like command line flags, but then you run into +e and the whole thing goes topsy turvy.
- gmjosack 13y agoI call my for loop variables idx. I never use single letter variable names, though I won't call someone out for it in a small block. Being able to highlight a variable in my editor, even when it's only used in a 5 line block of code is useful. Highlighting all letter i's is not.
- dllthomas 13y ago\<i\>
- gmjosack 13y agoIt's a lot easier for my fingers to type /idx than /\<i\> and it also easier to scan for idx than i. I'm not saying that everyone should do as I do but I find it frustrating dealing with single letter variables personally.
- dllthomas 13y agoI agree /\<i\> is a slight pain. Often the easiest way to get there is getting the cursor on one of the i's and hitting *.
- Too 13y agoWhat kind of editor are you using?! Any decent ide will give you syntax aware highlighting of selected variable, not word, and even most simple text editors highlight words separated by spaces, commas etc. I've never seen an editor that highlights the exact selection. I have actually missed that feature once or twice but for coding the other behavior is usually much more preferable.
- gmjosack 13y agoI just use vim.
- twic 13y agoI set both those options in every script i write. So i do it like this: #! /bin/bash -eu Because i do it in every script, readability and greppability are not important to me; i just need to apply the flags and get on with the script. Taking up two whole lines for them just adds noise. If i was more selective in my use of those flags, then i would agree that the long forms were preferable, for the reasons given.
- Hello71 13y agocausing your script to run incorrectly as `bash script`.
- stormbrew 13y agoDoes bash check the flags in the shebang if you run it with bash instead of directly?
- mturmon 13y agoOne drawback with this is that if you, or someone, does % bash script.sh to run your script, then the shebang line will never be seen, and your script will run with -e off. If the "set -e" is explicitly given, this won't happen. As you can guess, I've done this by mistake. One case is after transferring or unarchiving files where execute flags get turned off by mistake. Or using utilities, like job schedulers, that are tricky in whether they run the script as an executable, or via a shell interpreter.
- nhaehnle 13y agoBash scripting is one of those domains that people just randomly enter without a full walk through the documentation. It's one of those things that almost everybody learns by copy and paste. Given that, I think it's nice to be a bit more explicit, as it means the person who reads your script to copy and paste a bit out of it is more likely to learn something new in the process. Not that the copy and paste approach to learning a language is good, but that's how these things typically go in practice.