Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Also newer shells would be worth adding too: bash and zsh.


I currently teach a basic course in shell scripting at a university. I'm amazed that bash wasn't included! I don't know whether you'd include Make in there too, but I would - the two together still form the basis for the majority of software deployment in Linux, I reckon. Certainly all our research software uses these two technologies (still!)


Why would you want to mention bash in a course on shell scripting? All you'd do is produce more people writing gratuitously incompatible scripts.

I use bash as an interactive shell, but for scripts I can't imagine why anyone would want to use bash unless they simply didn't realize how non-standard it is.


It is the first time I hear that bash is non-standard.

For specialized tasks such as simple pipes, invoking a sequence of commands (for a more involved tasks I prefer Python) what else would you use other than your interactive shell?


what else would you use other than your interactive shell?

A POSIX shell. There is actually a --posix option to bash which makes it more closely approximate POSIX-standard behaviour, but last time I checked it wasn't perfect.


Bash isn't a standard shell. The Bourne shell (e.g. /bin/sh) is standard. There are Unices where bash isn't available (by default, or at all), and there's no reason to hardcode bash as the interpreter for a shell script unless you're using bash-specific extensions. (If you have to ask, you probably aren't.)

This is what's called a Linux-ism: "The Linux distro I use does it this way, so it must be the standard, right?" It's very annoying when porting things to BSD or elsewhere.


It depends whether you count standards as those decided by a committee, or those that people actually use. Sure, the various BSDs are quite active (and all have bash available through modern package management systems), but AIX, Solaris and HPUX are on the decline and have been for 10 years now.


Does it make sense to require bash as a dependency for a program that ignorantly hardcoded it in a two-line shell script in its test suite?

(I mean, I'd just patch it in the port, but it's annoying in the same way as people sending e-mail wrapped inside a Word file for no reason.)


Rational ignorance. The bash warnings about non-POSIX features have a reputation for being unreliable, so if I've only tested with bash (because I don't care enough to set up chroot) I shouldn't claim it works with any other shell.


No no no, I'm not saying it's testing a shell script, I'm talking about requiring bash for a script that literally says:

   #!/usr/local/bin/bash
   prog_name some_argument
Or, worse yet, programs that exec a command by using bash internally.


Well ... maybe using a shell to run a command worked differently in 1971. There's $IFS ... job control ...

Okay, yeah, there has never been a shell on which that wouldn't work. WTF bonus points for requring /usr/local/bin, which is almost certainly not where the OS maintainers package it.


The argument could be a filename. The filename could have a space in it. So yes, I'd use a shell that has $@ rather than $*, a settable IFS, etc.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: