19 ms·
Bash $* and $@ (2017)
- lallysingh 7y agohttp://tldp.org/LDP/abs/html/ http://tldp.org/LDP/abs/html/
- teddyh 7y agoAdvanced Bash-Scripting Guide, working link: https://www.tldp.org/LDP/abs/html/ https://www.tldp.org/LDP/abs/html/ (Your link, without “www”, gives me a certificate error.)
- lallysingh 7y agoIt was http. How'd you get a cert error?
- teddyh 7y agoProbably the “HTTPS Everywhere” browser extension; it has a rule for tldp.org: https://atlas.eff.org/domains/tldp.org.html https://atlas.eff.org/domains/tldp.org.html
- HocusLocus 7y agoThis is priceless. Countless times I have learned -- then later forgotten -- to use "$@" ... especially in cygwin's Windows 'spaces in filenames' territory
- orev 7y agoAt this point in time (i.e. 21st century), any *nix script or program that doesn’t handle spaces in files names is woefully buggy. Maybe 20 years ago this was excusable, but not now. Spaces can reasonably be expected to be in filenames in all systems. Support for other “special” characters in filenames (e.g. newlines), however, could still be debatable.
- enriquto 7y ago> any *nix script or program that doesn’t handle spaces in files names is woefully buggy. On the contrary! It is filesystems that support plain spaces in filenames that are broken. Filenames are variable names. Allowing separators in them is bonkers. I make a point of carefully crafting my scripts to wreak havoc whenever a user has spaces in their filenames.
- anoncake 7y agoGREATI~1.DEA
- michaelmrose 7y agoFile names are an interface used by normal people to name files. Teaching everyone to name their files differently seems unlikely to succeed. There is no particular reason your shell can't distinguish between a space inside a filename and the space between tokens in output. The fact that you have to do anything at all yourself is a bug.
- enriquto 7y ago> File names are an interface used by normal people to name files. Teaching everyone to name their files differently seems unlikely to succeed. Sure. But there's no reason why typing the spacebar on a GUI to input your filename should produce a file with a plain space on the filesystem. It could be a unicode non-breaking space, for example.
- ulrikrasmussen 7y agoIck. I have written my fair share of bash, and stuff like this is very common. Most things in bash are just inherently non-compositional and/or is riddled with weird corner cases that you just have to know about in order to not shoot yourself in the foot. This document [0] made the rounds on HN a while back, and it has, together with the associated tool, been something that I have regularly consulted whenever I have had to do anything non-trivial with bash (anything that has to deal with arguments to commands is already non-trivial to get right). [0] https://github.com/anordal/shellharden/blob/master/how_to_do_things_safely_in_bash.md https://github.com/anordal/shellharden/blob/master/how_to_do...
- deleted 7y ago[deleted]
- gpvos 7y agoIn the far past, it used to be necessary to use ${1+"$@"} because of some shells that didn't handle "$@" properly when it was empty.
- _kst_ 7y agoI've run into that. There was a problem with the OSF/1 /bin/sh that caused "$@" to expand to a single empty argument if there are no arguments, rather than to an empty list as it should. I just now removed a workaround for that problem from one of my scripts, 17 years after I added it. https://en.wikipedia.org/wiki/OSF/1 https://en.wikipedia.org/wiki/OSF/1
- downerending 7y agoAfter being challenged on this a few years ago, I checked with the shells available on Debian, and at least one still needed this. (dash maybe?) Just do it.
- throw7 7y agoAt one time, I did think python would replace my bash shell. Then I tried it. Either I'm an old dog or I was naive. Both are true, I think.
- jblow 7y agoWhy are we still using this in 2020?
- bori5 7y agobash is ubiquitous, and for me who grew up pre-python, which I probably should start learning for bash like tasks.
- jblow 7y agoToxic waste sites were ubiquitous too, but we put in the effort to clean them up.
- grayed-down 7y agoI'm game. What's your plan?
- DonHopkins 7y agoThis applies to bash as much as to X11 ICCCM: https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47 https://medium.com/@donhopkins/the-x-windows-disaster-128d39... In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry’s standard naked emperor. Using these toolkits is like trying to make a bookshelf out of mashed potatoes. - Jamie Zawinski X-Windows: …Even your dog won’t like it. X-Windows: …The first fully modular software disaster.
- yjftsjthsd-h 7y agoBecause nobody has written a good (universal) alternative. POSIX sh is available everywhere and is extremely well suited to gluing things together.
- HorstG 7y agoIf you need a portable replacement, there is Perl. Available since the last century. If you don't care about obscure Unixes, there is also Python and a whole bunch of other scripting languages on more modern systems.
- mattbillenstein 7y agoOh man, wish I'd seen this a few days ago - ended up doing something ugly using printf and xargs...
- gpvos 7y agoUse perl instead.
- mattbillenstein 7y agoWORSE
- gpvos 7y agoNot really, but I guess tastes differ. Perl is still my go-to language for anything that's just too much for a shell script.
- mikelward 7y agoYou should try stackoverflow or unix.stackexchange.com. e.g. my answer https://unix.stackexchange.com/a/41595/3169 https://unix.stackexchange.com/a/41595/3169
- mattbillenstein 7y agoHmm, still not able to do what I want with this -- I want to take an argument like: foo.sh --clean bar.yml And actually run something like: blah -e '{"clean": true}' bar.yml where -e and the thing in '' are two separate args...
- acdha 7y agoIf you’re writing shell scripts you should have https://www.shellcheck.net/ https://www.shellcheck.net/ in your editor and pre-commit hooks to catch common footguns. Even then, my threshold for “this should be Python” has shrunk over the years: I used to say “greater than one screen of code” but now it’s more like “>1 branch point or any non-trivial scalar variable”.
- mysterydip 7y agoA common problem that happened to a coworker was he made a quick bash script for something simple, then kept adding "just one more" thing with sunk cost fallacy not wanting to take the time to rewrite it. Eventually the monstrosity created was too difficult to debug and it had to be rewritten in a different language.
- Jade_Jet 7y agoI’ve seen the same thing happen with any language. Generally tends to happen when a dev hasn’t thought through the scope of what they are doing beforehand. I’ve written some ugly python in my earlier days due to this as well. My point here is it is less to due with the language and more to due with the mindset when solving a problem. The main issue I see with more inexperienced devs with bash is that they tend to think it’s okay to be lazy with the code because it’s just “bash”. If you would write safety checks and comments in your python you should be doing the same in bash really.
- scbrg 7y agoAnother rule of thumb would be: "How many years from now do you still want this to work?" If I run a shell script I wrote ten years ago, it works. If I run a Python script I wrote ten years ago, it's quite likely to fail with a SyntaxError. This, I say as someone who loves Python and I use it as my primary language both privately and at work. But I have to admit, Python scripts do not really age well.
- np_tedious 7y agoI'm really struggling to think of an example that doesn't involve py2 --> py3. Can you share a few?
- hapless 7y agoIt's 2020. Friends don't let friends write shell scripts.
- etaioinshrdlu 7y agome: What if there was a programming language as inconsistent and terrible as English, maybe it would be uniquely easy for humans to understand? bfox (wrote bash): Nah, Bash disproves that.
- humblebee 7y agoWhat do you recommend instead?
- deleted 7y ago[deleted]
- BossingAround 7y agoWhen I first came into the world of SWE, I thought "why would anyone use Bash nowadays when we have Python?" A colleague answered me: "If we left, there's around 500 people in this building who could support my Bash script, and around 50 Python people." It kind of stuck with me. At this point, I feel like Bash is one of the common tongues between all tech roles (that deal with Linux, that is). Python, while nice, is a lot more niche, since you really have to be into development to know Python, while every sysadmin worth their salt can debug a Bash script. And, of course, every SWE, TSE, DOE, .... worth their salt know Bash scripts as well. If you want to get a job (in the Linux land), bash scripting is typically an "of course".
- HorstG 7y agoThere are lots of those footguns in shellscript. One should always try to avoid any shell and rather use python, tcl, perl or powershell. Any criticism one might have about insecure and broken by design languages apply doubly to shell. A short list of possible problems (of course depending on the shell in question): spaces in filenames newlines in filenames nonprintables in filenames empty variables and their expansion ([ x$foo = "xsomething" ]) errors in pipes environment madness /bin/bash ?= /bin/sh Arrays or the lack of it Space separates lists as arrays #!bash vs. #!/bin/bash vs. #!/usr/bin/env bash vs. #!/usr/sfw/bin/bash vs. ... Unwritable and unreadable control structures (if [], case, &&,...) Information leaks via ps and many others... Never use shell except to search for and invoke a sensible language. And anything is more sensible, including C, Perl, brainfuck and Basic.
- AmericanChopper 7y agoI like powershell, but it has its own arsenal of footguns for you to use. Things like non-terminating errors and the sometimes confounding behaviour of automatic variables comes to mind.
- TheDong 7y agoI believe your diatribe is misplaced. There are quite a few pitfalls in shell scripting. You can considerably reduce them by limiting yourself to only being compatible with modern versions of bash and settings things like pipefail, nounset, etc etc. I do agree that in general a good programming language will be a better option. > anything is more sensible, including C, Perl, brainfuck and Basic I do disagree with that however. A 5 line bash script may be 500 lines of C, will take a hundred times longer to write, and may contain memory safety issues (which the bash script at least wouldn't). I know brainfuck is hyperbolic so I won't argue against that. Something with no filesystem or process forking abilities obviously can't be used for any real task. I think perl and basic have just as bad syntax as bash though, if not worse. Basic's penchant for "GOTO" is awful, perl's syntax as a whole is just as peculiar as bash's in many places. I guess my overall point is that bash is usually not a good option compared to modern languages, but it's a darn sight better than you give it credit for. I think it still has its place for 5 or 10 liners that are easy to express and read in bash and don't need any abstractions beyond what coreutils provide.
- TheDong 7y agoThe article doesn't mention it, but very similar syntax is also used for arrays. For example: arr=(a b c) arr+=(d) ls "${arr[@]}" # ls "a" "b" "c" "d" ls "${arr[*]}" # ls "a b c d" This has quite nice symmetry with the fact that the 1st argument is "$1", and you replace the number with these symbols, and for arrays you access elements with "${arr[1]}", and again replace the number with the same symbols for the same behaviour. If you do a lot of bash scripting, arrays are invaluable.
- useragent86 7y agoIndeed, and actual Bash scripting (as opposed to plain POSIX sh) is much more pleasant. Used properly, arrays make it easy to build commands with arguments and finally run them, e.g. #!/bin/bash command_args=( --foo bar --baz "buzz buzz" ) [[ $frob_option ]] && command_args+=(--frob frab) echo command_name "${command_args[@]}" "other" "arg" # Echoes: # command_name --foo bar --baz "buzz buzz" --frob frab other arg
- deleted 7y ago[deleted]
- roryrjb 7y agoShell scripting is absolutely still relevant. The rule of thumb should not be about length but about complexity, specifically if you absolutely need something like a real array or a hash then move onto a different language. Use shellcheck and avoid bash for scripting. I use bash or pdksh interactively but stick to POSIX shell for scripting. I am finding myself writing POSIX shell all the time and having great success with it.
- gameswithgo 7y agoit is, but should it be?
- pletnes 7y agoWhy not bash? It’s in most places, even if POSIX is even more general. And it does add some nice scripting features. I use zsh for interactive and bash for scripts for the same reasons as you, though.
- smichel17 7y agoBecause when you find yourself needing bash-specific features, alarm bells should be going off. POSIX sh is good at reminding you to KISS and delegate to other tools.
- fiddlerwoaroof 7y agoI write my scripts in zsh, because its extensions are most useful in scripts, and it’s not too hard just to make it available everywhere you need to work (e.g. you can compile it to be installed in ~/zsh and just copy the installation to your home directory on any machine you need to use. Things like array-linked variables ($path is an array version of $PATH and modifications to one propagate to the other), associative arrays (dictionaries in python) and a handful of other really nice tools (e.g. saner white space handling) make going back to bash for scripts unpleasant.
- roryrjb 7y agoYeah don't get me wrong the bashisms are useful, but I'm hopping between OpenBSD, FreeBSD and Linux (and perhaps sharing scripts with my macOS-using colleagues) and although bash is available on all those platforms and more, POSIX shell will work out of the box without any further configuration.
- clort 7y agoThis is not Bash specific, this is basic POSIX shell: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_02 https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V... Bash also incorporates the POSIX shell, but has extensions. This is fine if you are using it, but if you are writing a script which may need to run on another system, its better to keep it to POSIX. (edit: URL - thanks userbinator)
- deleted 7y ago[deleted]
- userbinator 7y agoYou probably meant to link to the shell section of POSIX? https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18 https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
- clort 7y agoYes, in fact the 'Special Parameters' section. I didn't notice it was relying on session cookie
- floatingatoll 7y agoThe only time you should use $* is inside a debug message like "unable to open $* ($!)". If you’re passing around arguments, always use "$@". If you know enough bash to disagree, you know enough bash to use the third case safely :)
- eikenberry 7y agoI was going to say the same thing (so I will). The rule is just always use "$@" and then you have only one case to reason about and it is what you want 99.99% of the time anyways.
- dnautics 7y agoI think it's also reasonable to use in ssh and I believe su, which are commands that expect a single string as their inner command parameter.
- floatingatoll 7y agoI can count on ten fingers the number of times in twenty years I've worked with another bash coder who did the su and ssh cases correctly without triggering escaping bugs. It's not any insult on them, but it's almost always done incorrectly and happens to work due to the absence of whitespace and backslashes, leading to eventual bugs (that Shellcheck won't always catch). Given: # ARGV=( "one two", "three four" ) It's probably safe to recommend "$@" for use with su only whenyou use -c correctly, as you're locally specifying the args without any further IFS interference. But $* isn't usable: # CORRECT su root -c 'rm "$@"' -- "$@" rm "one two" "three four" # incorrect su root -c "rm \"$@\"" rm one two three four # wrong arguments # incorrect su root -c "rm" "$@" rm # -c doesn't use arguments # incorrect su root -c 'rm "$@"' "$@" rm "three four" # loses the first argument (?!) # incorrect: su root "rm" "$*" rm one two three four # wrong arguments # incorrect: su root "rm $*" "rm one two three four" # command not found It's probably safe to recommend "$@" for use with ssh only when using printf %q to ensure that you escape your arguments for their transit through ssh to the remote host, as otherwise the arguments get corrupted by the extra layer of shell processing. $* isn't usable here either: # CORRECT ssh remote -- 'rm '"$(printf '%q ' "$@")" rm "one two" "three four" # incorrect ssh remote 'rm '$(printf '%q ' "$*") rm "one two three four" # wrong arguments # incorrect ssh remote rm "$@" rm one two three four # wrong arguments # incorrect ssh remote "rm \"$@\"" rm "one two three four" # wrong arguments # incorrect ssh remote 'rm "$@"' "$@" rm one two three four # wrong arguments # incorrect: ssh remote "rm" "$*" rm one two three four # wrong arguments # incorrect: ssh remote "rm" "$*" rm one two three four # wrong arguments EDIT: Shellcheck misses 3 of the 4 broken su cases, but catches all of the broken ssh cases. (And produced a warning I disagreed with in one of the complete examples, but in the spirit of things, added double quotes to silence it.)
- chubot 7y agoOil [1] supports all of this old syntax to run existing shell scripts, but has new syntax which is more convenient. - You can write @ARGV instead of "$@". - You can write @myarray instead of "${myarray[@]}" (Related: Thirteen Incorrect Ways and Two Awkward Ways to Use Arrays https://www.oilshell.org/blog/2016/11/06.html https://www.oilshell.org/blog/2016/11/06.html ) Example: oil$ var myarray = @('has spaces' foo) oil$ var s = $'has\ttabs' # function to print an array element on each line oil$ lines() { for x in @ARGV; do echo $x; done } # pass 3 args -- 2 from myarray and 1 from s oil$ lines @myarray $s has spaces foo has tabs [1] https://www.oilshell.org/ https://www.oilshell.org/
- dzidol 7y agohttps://xkcd.com/927/ https://xkcd.com/927/
- chubot 7y agoUnlike every other alternative shell, Oil runs existing bash scripts to avoid this problem.
- XelNika 7y agoI don't really think Oil is relevant to this topic. The only good reason I can think of for someone to script in bash is for portability purposes. If someone wanted portability without bash's shitty syntax, something like Python would be a much better candidate than Oil. One could also argue that there's no meaningful difference between e.g. fish scripts and Oil scripts because neither will work on the standard shell. It's also possible to run bash scripts from fish by simply calling bash. Right now, Oilshell is a reasonable choice for an interactive shell with bash compatibility, whereas Oil syntax is just as, if not more, useless for public distribution as fish. As I see it, the goal for a project like Oilshell (a shell with both a new syntax and support for standard bash syntax) would be to replace bash as the default shell in distros. Until then, Oil scripts lack the primary feature of bash scripts just like other alternative shells.
- pletnes 7y agoI highly recommend this site. It’s very nitpicky, and that’s the only way to write somewhat robust shell scripts. https://mywiki.wooledge.org/BashGuide https://mywiki.wooledge.org/BashGuide
- layoutIfNeeded 7y ago+1 This is where I’ve learned proper bash. People always compliment my bash skills, but the only thing I do is sticking to the wooledge wiki’s rules + using the unofficial bash strict mode (http://redsymbol.net/articles/unofficial-bash-strict-mode/ http://redsymbol.net/articles/unofficial-bash-strict-mode/).
- dwheeler 7y agoIt's not just bash, this is true for all POSIX shells (including dash, bash, ksh, and so on). If you're doing a lot of complex calculations, shells are the wrong tool for the job. But if it's a relatively small program whose primary task is invoking other programs on a Unix-like system, shells are still a decent choice. The biggest problems with shells are handled by using shellcheck, so if you're writing shell scripts, use shellcheck.
- ljm 7y agoMan, one of the worst debugging experiences of my life was when we built an extensigble build tool, based on Bash. Most of it worked, but there was always an inconsistency between $* and $@ and there would be PRs that swapped those values around, back and forth. They were both totally valid; we just hadn't agreed on a calling convention for the tool so people were trying to fix their individual problems based on their own habits.
- mikelward 7y agoThey are not both totally valid. You almost always want "$@". If you're using $* , you're not supporting arguments that contain spaces, and you'll break if arguments contain wildcards. If you're using "$*" , you're treating multiple arguments as a single argument. https://unix.stackexchange.com/a/41595/3169 https://unix.stackexchange.com/a/41595/3169
- a1369209993 7y ago> there was always an inconsistency between $* and $@ There is never a legitimate reason to use $* . Even in the rare cases where you want those semantics (hint: you don't), you should use something like "$(join ' ' "$@")" instead. > They were both totally valid; No, they weren't.
- 3xblah 7y agohttps://www.in-ulm.de/~mascheck/various/bourne_args https://www.in-ulm.de/~mascheck/various/bourne_args
- thennegah 7y agoLol, we just made a bash function using this. // echo_and_run() { echo "$*" ; "$@" ; } Logs the cmd before running.
- gcmeplz 7y agoYou can also use `set -xv` to get nice debugging logs https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html#The-Set-Builtin https://www.gnu.org/software/bash/manual/html_node/The-Set-B...
- marcacohen 7y agoHere's an easy way to see how this works. Run this script: echo dollar-star: for i in $; do echo $i; done echo dollar-at: for i in $@; do echo $i; done echo quoted-dollar-star: for i in "$"; do echo $i; done echo quoted-dollar-at: for i in "$@"; do echo $i; done ./x.sh a "b c" d dollar-star: a b c d dollar-at: a b c d quoted-dollar-star: a b c d quoted-dollar-at: a b c d
- yesenadam 7y agoHN gobbled your stars.
- _kst_ 7y agohttps://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc Blank lines separate paragraphs. Text surrounded by asterisks is italicized, if the character after the first asterisk isn't whitespace. Text after a blank line that is indented by two or more spaces is reproduced verbatim. (This is intended for code.) Urls become links, except in the text field of a submission.
- lalaland1125 7y agoI highly recommend that people learn how to use https://docs.python.org/3/library/subprocess.html https://docs.python.org/3/library/subprocess.html as a replacement for Bash. It's a little more work upfront, but it's vastly more maintainable.
- ben509 7y agoI disagree. Here's a warning from subprocess[1]: > Use communicate() rather than .stdin.write, .stdout.read or .stderr.read to avoid deadlocks due to any of the other OS pipe buffers filling up and blocking the child process. The trouble with `communicate()` is it only handles very simple cases, basically, your output has to fit in memory. Same problem exists in asyncio.[2] Yes, you can usually work around this. That doesn't mean it's a good replacement; whereas complex pipelines are so trivial in bash that any user-defined function can be used in a pipeline, subprocess generally forces you to do the dumb thing and create a mess of temporary files. And that's not even considering you're writing 10 times as much code than you would to accomplish the same task. [1]: https://docs.python.org/3/library/subprocess.html#subprocess.Popen.stderr https://docs.python.org/3/library/subprocess.html#subprocess... [2]: https://docs.python.org/3/library/asyncio-subprocess.html#asyncio.asyncio.subprocess.Process.stderr https://docs.python.org/3/library/asyncio-subprocess.html#as...
- kortex 7y agoWhy is this still such a problem? People have been talking about replacing bash with python for years, and yet trying to actually do just that, is a pain. Plumbum doesn't quite cut it. I think in part it's because the POSIX-style shell is so tightly wound with the OS, it's extremely proficient at spawning and forking processes, working with files, and communicating, and that experience is seamless. Python feels like a different world, and doing any subproc, pipes, or file i/o always feels like crossing some boundary and back.
- detaro 7y agoI feel like this could be a situation parallel to JS on the web: You can change the language that's available everywhere only slowly and in limited ways, so people build compilers targeting it as the output language from "nicer" languages.
- baby 7y agoThat's why I hate bash and Makefiles. The syntax is just so cryptic that if you don't write/read bashfiles/Makefile for a while it's just impossible to get back into it.
- eikenberry 7y agoI agree to an extent about Makefiles, though I still think they are useful as long as you keep to a simple subset of their functionality. Shell scripting is a different matter. One of the great things about shell scripting is that you can never forget it because you are using it constantly to interact with your system. The fact that it is something you use constantly and can just take and stick in a file and re-use is one reason why shell scripts are so popular.
- mangamadaiyan 7y agoIsn't that true of any nontrivial programming language?
- baby 7y agoI don’t think so. Bash is more cryptic than any language I know besides brainfuck. Also why use a nontrivial language for scripts?
- AlexCoventry 7y agoYou should try APL.
- cyborgx7 7y agoI think the basic idea of make is brilliant and still very useful. Compare time stamps of files and if there is a file A that is newer than file B and that is needed to make file B, then make B again, with the provided command. The problem is trying to put any more functionality into it than that. Everything more complex than this basic functionality should be instead implemented in a script that gets called by make to rebuild the given file.
- j1elo 7y agoThing is, if the script is basically the glue between incantations of multiple other commands (which is basically the intended use case of shell scripting), then replacing that with Python[1] is just adding lots of boilerplate code for no real improvements in functionality. I still agree with a strict limit on the acceptable complexity, though. Most if not all my shell scripts are just piping executions of external commands. I find all the code needed to properly run a process and process its output is much easier with the UNIX toolbox and a couple of pipe commands, than having to handle all those input/output buffers, command execution modes, etc in any other shell script language. OTOH Plumbum [2] has been mentioned here, and it seems fantastic for that use case. But I think the issue is obvious, in that it took a conversation in HN to raise awareness of this tool: it is not officially promoted, or recommended even, as the solution for replacing shell scripting, so it is kind of obscure (unless you are actively into the language or somehow by chance end up getting to know about it, that is) There is also the thing about choosing Python to replace Bash scripts would force having to install Python in all of the project's Docker images, while a short POSIX script works as-is. [1]: Saying Python because that's the most common suggestion for replacing Bash. [2]: https://plumbum.readthedocs.io/en/latest/ https://plumbum.readthedocs.io/en/latest/
- arminiusreturns 7y agoI've seen way too many devs try to recreate gnu coreutils their way because of a silly aversion to bash. As a sysadmin (sorry, thats not popular these days cough Ops guy) you can pry the bash out of my cold dead hands, and most of the "wierd edge cases" are easily avoided just like those of any language. I know everybody likes to think devops and cattle/pets and "you should never ssh into machines" are how things should be and there thats how they are, but in the real, non-sv software startup world sysadmins around the world who get that 3am call are fixing some devs shit with bash and sysv/systemd scripts. I feel at this point it's just a bandwagon people jump onto because they want to feel superior. Just mention bash on HN and expect any number of "... don't use bash" comments. Bash best practice is always double quote variables! Do that and the post becomes rambling about what happens when you dont follow standard bash practices.
- Lammy 7y agoWhat about my aversion to m4? =P
- arminiusreturns 7y agoIf know m4 enough to have an aversion to it you can do what you want. [ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo “click”
- garaetjjte 7y agoCylinder shouldn't be stateless..
- perl4ever 7y agoI advise picking up the money that's closest and running while your dog holds off the nymph and the rest.