Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stronger Shell

m.odul.us

Post reply on HN
Print view View original

31–40 of 80 posts

Re: Stronger Shell

#31

Post by anh79 »

leni536 wrote: post #26
realharo wrote: post #6

I personally can't stand bash for writing scripts (it's fine for typing one-liners into terminal though). This question and its top answer capture the insanity of bash quite nicely http://stackoverflow.com/questions/3601515/how-to-check-if-a... .

> This is because it doesn't distinguish between a variable that is unset and a variable that is set to the empty string. Yeah, this is insane and the default settings of bash are quite horrible. You can set some bash options in the beginning to avoid such problems. For the StackOverflow problem "set -o nounset" can be a good safeguard. Other options to look into to safeguard bash scripts from some insane behavior ar…

All lessons I've known https://github.com/icy/bash-coding-style/blob/master/LESSONS...

Re: Stronger Shell

#32

Post by chriswarbo »

Was worth reading if only to find out about ShellCheck.

My current project has a lot of bash. The program itself is just `foo | bar | baz | ...`, but the associated test script has grown quite long.

I've just added an extra test which calls shellcheck on each script, and it's spotted a bunch of redundant code for me :)

Re: Stronger Shell

#33

Post by anh79 »

Bash is good as a system shell. For interactive shell, zsh/fish/... wins.

That's why I only learn Bash. One lesson for everything for both purposes ;)

Re: Stronger Shell

#34

Post by tachion »

What suprises me is how often Bash is being used as 'the shell' and software projects use it, even when they could simply call /bin/sh instead. This is particularly bad for people who port software to other platforms (where BSD systems dont come with Bash, for example) and have to deal with pure shell scripts calling Bash. One recent example is CoreOS/etcd that's currently dropping Bash in favor of Sh, because they simply didnt need it.

Bash is a shell, but Bash is not the shell!

Re: Stronger Shell

#35

Post by omtose »

agentultra wrote: post #18
_yy wrote: post #15

Earlier quoted context omitted.

There's fish: http://fishshell.com/ Also, a nice experiment: http://xonsh.org/ (Bash-alike with embedded Python)

I second fish. I've been using it as my primary shell for more than a few years now. The syntax is better than bash and familiar to those who've done programming in languages like Ruby or Python. The line editor is actually useful. It handles indentation and highlighting. It will display an appropriate help page if you mess up some command. It comes bundled with argument completion for most common Unix tools and is e…

With that example in particular, fish by default does not mess up file names containing spaces, as opposed to bash which treats them a separate files. I'm not sure why, but it's certainly useful.

Re: Stronger Shell

#36

Post by leni536 »

anh79 wrote: post #31
leni536 wrote: post #26

Earlier quoted context omitted.

> This is because it doesn't distinguish between a variable that is unset and a variable that is set to the empty string. Yeah, this is insane and the default settings of bash are quite horrible. You can set some bash options in the beginning to avoid such problems. For the StackOverflow problem "set -o nounset" can be a good safeguard. Other options to look into to safeguard bash scripts from some insane behavior ar…

All lessons I've known https://github.com/icy/bash-coding-style/blob/master/LESSONS...

Some of these are programmer errors though. Quote everything is known best practice for bash, vim lints unquoted variable expansion as red. Also bash scripts frequently interact with the FS so it's no surprise that some bugs remove files that are not meant to be removed. I think "set -o nounset" would stop the RHEL bug, although it's not clear if the variable is unset or really just an empty string.

I don't want to protect bash though, but teaching bash scripting best practices would be nice. I learned these options from this site:

http://kvz.io/blog/2013/11/21/bash-best-practices/

Re: Stronger Shell

#37

Post by faitswulff »

roneesh wrote: post #5

I'd be remiss if I didn't use the comments to mention the amazing and totally free, "Unix for the Beginning Mage". The author of the article also didn't mention this great resource. It's an amazing book and a short read. It took me about 3 hours to work through completely. www.unixmages.com If you don't know how to use your shell, block yourself off an evening with this book and change how you forever use you compute…

I, too, was looking for this in his list. It's a really great resource.

Re: Stronger Shell

#38

Post by estrabd »

I generally avoid aliases. I prefer to rote learn complex commands; if it's fitting for an actual shell script then I'll just bang one of those little guys out in no time.

Re: Stronger Shell

#39

Post by jlgaddis »

heydonovan wrote: post #29

Just about everything I've learned about bash has been from the #bash IRC channel on Freenode. You'll see the same repeated warnings of not learning from the public web, due to the fact that misinformation spreads like a wild fire, and some articles out there are just flat out wrong (sort of like w3schools in the #css circle). There is just one thing I will never understand. The tired argument of "...but it isn't por…

Depends what you're going for, I guess. If it's something you're developing for public use and/or something you want to run on !Linux, portability might be a concern (FreeBSD, for example, doesn't ship with bash and, if you install it, it lands in /usr/local/bin instead of /bin).

Re: Stronger Shell

#40

Post by felixgallo »

useerup wrote: post #13
david-given wrote: post #8

Earlier quoted context omitted.

Is there a better shell? By which I mean more flexible, more consistent, and simpler. (Anyone who says 'zsh' is disqualified.) I've briefly looked at rc, but while it's significantly simpler and more orthogonal than sh it's got it's own weirdnesses; but the 'Design Principles' section here is worth reading: http://plan9.bell-labs.com/sys/doc/rc.html Surely there must be a usable shell wrapped around an actual modern…

> Is there a better shell? By which I mean more flexible, more consistent, and simpler. Yes, PowerShell. And it may actually arrive at Linux/Unix soon, due to CoreCLR. The specification is already open, but until now not much progress has been made towards bringing it uncrippled to Linux/Unix PowerShell is extremely consistent. Examples: All commands are strictly on the verb-noun form where there are only 40 or so "a…

I had an opportunity to use PowerShell recently. The task was simple: on a bunch of freshly installed windows 8 boxes, kill a running graphical program of a certain name, copy over new executables, and restart that graphical program. The kind of thing you do essentially constantly on Unix boxes.

I urge anyone at all with any interest in PowerShell to give it a shot. Spoiler: it's not possible without an epic level of hackery; but along the way, you will uncover that PS uses the same parameter to mean very different things for different commands, that the 'everything is an object' conceit doesn't work when the object you want doesn't exist, that PS is chock full of hacky, revolting cruft already despite its youth, hacky revolting cruft that makes oh-my-zsh look like /bin/rc, that most windows commands will fill your screen with banner(8) style output even on success, and that no two windows commands are alike.

Given which decade it was developed in, PowerShell represents the most absolute and fundamental failure of software I've had the pleasure of encountering in the last five years; and I've seen Windows 8.0. Anyone who thinks PowerShell is at all any good has, axiomatically, never seen any other shell besides cmd.exe before. You may think I'm exaggerating. Please, try the example above, then report back here with a list of what you had to do.

Post reply on HN