111–120 of 272 posts
I have never used bash scripts professionally i.e. as a language rather than a simple script with just a command in.
Like wise back in 87 or so I got trained in sed and I have only used it once since, and that was when I was playing around with early linix's (when it came on a huge number of floppys)
Earlier quoted context omitted.
If foo has a Texinfo manual (GNU tools like bash usually do) then you can try `info foo` and search the index with i or I for -p. Texinfo manuals also have hyperlinks you can press enter on. info is a greatly underused system and I'd recommend any *nix users to spend some time learning how to navigate it.
Thanks. Is there a good way to open that in a browser, rather than a console?
Earlier quoted context omitted.
Would you consider non-trivial install scripts as an exception to this general rule? I mean, you wouldn't write some install script in ruby or python, right?
Yes, you would write non-trivial install scripts in ruby. https://en.m.wikipedia.org/wiki/Chef_(software)
Interesting but from a modern perspective is not perl a better scripting language to learn. I have never used bash scripts professionally i.e. as a language rather than a simple script with just a command in. Like wise back in 87 or so I got trained in sed and I have only used it once since, and that was when I was playing around with early linix's (when it came on a huge number of floppys)
I hadn't known that <(echo "hi") is treated as a file with the contents of stdout, which simplifies commands that take files as arguments.
> if [ x$(grep not_there /dev/null) = 'x' ] This is still wrong if the command can output spaces or meta-characters. You should quote the left operand, and then you don't need to prepend x: if [ "$(grep not_there /dev/null)" = '' ]
Does the second only work with bash? Because IIRC it didn't work with FreeBSD's /bin/sh, you needed the initial x too.
$ grep somestring file1 > /tmp/a
$ grep somestring file2 > /tmp/b
$ diff /tmp/a /tmp/b
The manual for bash consists of its Unix-style "man" page, and is therefore more of a reference than an instruction manual. I suggest using the Advanced Bash-Scripting Guide (http://tldp.org/guides.html#abs).
I wrote a book on Bash too. The most important thing for anyone to know about Bash is that it's intended as a command language, not a general purpose scripting language. If it's longer than 10 lines, or if it uses two or more variables, you should probably have written it in something other than Bash.
Would you consider non-trivial install scripts as an exception to this general rule? I mean, you wouldn't write some install script in ruby or python, right?
We support a lot of different OSes, and there's usually less variance between the Perl deployed on them than there is in the shell.
My take on the same topic: - use the unofficial strict mode: http://redsymbol.net/articles/unofficial-bash-strict-mode/ - use parameter substitutions like ${foo#prefix}, ${foo%suffix} instead of invoking sed/awk - process substitution instead of named pipes: () - know the difference between an inline group {} and a subshell () - use printf "%q" when passing variables to another shell (e.g. assembling a command locall…
some-command