Live data from Hacker News

Shell Style Guide

google.github.io

191–200 of 336 posts

Re: Shell Style Guide

#191

I don’t understand all the hate for bash or python in this thread. These are programming languages. Like all programming languages one must understand how to deploy them and use them properly. Yes bash has faults absolutely. It can be very arcane and esoteric and I think this due to the fact that it’s creators are very much of the old 1970s and 1980s Unix mindset and largely bash tools still feel like they work the w…

I actually like python, the language. I think it balances the needs of a dynamic language well and I like that it is, at least, strongly typed. My hate is entirely directed at python, the environment and tooling around the language. Other languages have figured this stuff out and python just hasn't. And the horribly managed 2.x -> 3.x migration made things even worse.

I get that it is enjoyable to program in and I think it makes a fine choice for instances where a whole team is bought into the decision to use it. But when it's used for things that are distributed to others or force other people who aren't experts in python to wade into the ugliness of the python ecosystem, that's what makes me hate it. I've had so many python-related problems with the aws command-line client alone, let alone all the other python I've been forced to run, that I never want to touch another product written in python again.

To me, it's just an instance of developers prioritizing themselves over their users (hello electron devs).

Re: Shell Style Guide

#192
post #165

Earlier quoted context omitted.

> You have to do everything manually You are aware that error handling is done via exceptions python?

You are aware that there's no compiler, and that you have to write the try-except-finally? I'm talking about how weak guarantees Python gives compared to Bash about the correctness of the program. It's easy to get None-s, it's too easy to forget to handle file not found or lack of permission.

For most scripts, handling file not found isn't gonna happen anyway. Often the result is just printing to standard out "hey I couldn't find file X" then bailing. An uncaught exception works well enough for this in many cases, such as build scripts.

Same goes for permissions issues and a whole slew of similar scenarios. For many use cases, the lack of forced error checking is a feature.

Concrete example: build scripts. As long as the cause of the build failure is clear from the uncaught exception, there's no reason to handle it. I don't need a friendly UI to avoid scaring off non technical users, I just need something that handles the happy path well and crashes with a meaningful stack trace when something unexpected happens.

Re: Shell Style Guide

#193

I don’t understand all the hate for bash or python in this thread. These are programming languages. Like all programming languages one must understand how to deploy them and use them properly. Yes bash has faults absolutely. It can be very arcane and esoteric and I think this due to the fact that it’s creators are very much of the old 1970s and 1980s Unix mindset and largely bash tools still feel like they work the w…

> no single language is objectively superior to another I would say some languages are objectively superior to other for specific tasks. The problem is that very often the task to solve doesn't exactly fall within the realm of any given programming language and one has to make compromise. As for bash, I use it when I feel it's the best option, but I also think it's the worst programming language that I have to use. I…

Yeah, trivially, a language like Brainfuck is clearly not a good choice for anything professional or maintainable; therefore, there must be some selection criteria that makes some languages objectively better than other languages.

Whether PHP is a "bad" language or C# is better than Java is harder (and generally a waste of time -- pick something that works 95% of your use-case and figure out the other 5%), but refining the phrase to "no commercially used language is objectively superior to another" starts to make the statement useless to the point of irrelevance.

Re: Shell Style Guide

#194
post #105

Earlier quoted context omitted.

I really don't like the `/usr/bin/env bash` approach (it came from the ruby world I think?). It's less portable than /bin/bash in my experience - I've been in environments, usually older ones, where it doesn't work at all. But /bin/bash works everywhere. You also can't pass command line arguments. And it's slightly more complex than just invoking /bin/bash.

> It's less portable than /bin/bash in my experience /bin/bash breaks on FreeBSD, which installs Bash at /usr/local/bin/bash. /usr/bin/env bash works though. > You also can't pass command line arguments. Are you sure about that? Given this script: #!/usr/bin/env bash echo "args: $@" it outputs: $ ./foo 1 2 3 args: 1 2 3 Is that what you meant?

You can do “/bin/bash -e” but not “/usr/bin/env bash -e”. Same for python etc.

Good point about freebsd - I remember running into that exact problem. But I think I just symlinked it.

https://unix.stackexchange.com/questions/29608/why-is-it-bet... has more info on the pitfalls.

In my experience env causes problems, whereas explicit binary call always works (assuming the path exists). Not sure why I was downvoted.

Re: Shell Style Guide

#195

I don’t understand all the hate for bash or python in this thread. These are programming languages. Like all programming languages one must understand how to deploy them and use them properly. Yes bash has faults absolutely. It can be very arcane and esoteric and I think this due to the fact that it’s creators are very much of the old 1970s and 1980s Unix mindset and largely bash tools still feel like they work the w…

I like bash, but I think I understand the hate -- it's the slippery slope of "gluing real applications" to "I can write this all in bash!". Just because you can, doesn't mean you should.

If the application can be reduced to some form of simple piping of existing programs...

Re: Shell Style Guide

#196
post #33
post #19

Earlier quoted context omitted.

Maybe one day there will be another cool and dominating shell. That shell is more likely to be POSIX compliant than bash compliant.

All the cool new shells I've seen are either completely POSIX incompatible (powershell, xonsh, etc.) or they try to be bash supersets (zsh, osh, etc.). Bash is a de facto modern standard. The only new purely POSIX shells I know are for embedded stuff (dash) and that space is neither fast moving nor in dire need of a better shell, since most modern shell features target interactive use. Or they make coding easier and/…

Maybe the missing POSIX compatibility is the reason why they haven't replaced bash yet.

Re: Shell Style Guide

#197

Earlier quoted context omitted.

> Wow, this comparison is totally whack Did you really say whack? > Javascript and C are both standardized and the former is the only option when using a web browser. Javascript isn't the only option. It is the most popular by far and hence the "de facto" language of the web. And javascript certainly isn't "standardized" in the sense you are writing. Do you know anything about web development, browser implementation…

>Javascript isn't the only option. It is the most popular by far and hence the "de facto" language of the web. And javascript certainly isn't "standardized" in the sense you are writing. Do you know anything about web development, browser implementation of javascript and javascript itself? Javascript is no more "standardized" than SQL is standardized. Every RDBMs implements their own flavor of SQL just like browsers…

> This is nonsense [...] You're off your rocker.

Come on Drew, you know better than to do this here, regardless of how wrong someone is. If senior users set this kind of example how can we tell new ones not to?

https://news.ycombinator.com/newsguidelines.html

Re: Shell Style Guide

#198
post #5

The only thing I'd quibble with is the recommendation of [[ ... ]] over [ ... ], because shell programmers used to [ will be surprised that [[ "foo" == "f*" ]] does pattern matching. But that is more or less an arbitrary style preference. One thing I'm curious about is whether Google machines have followed Debian etc. in making /bin/sh a faster non-bash shell, or if /bin/sh is bash.

I'm on a google machine now and it's a symlink to /bin/bash.

Re: Shell Style Guide

#199

Earlier quoted context omitted.

And on Windows there is something better than Bash, called PowerShell.

Not to put too fine a point on it, but that's nonsense. Historically, PowerShell was supposed to be a replacement for cmd.exe and roughly equivalent to bash, yet suitable for the Windows environment. They tried early on to port some of the UNIX & Linux tools to Windows and it didn't fly, so this is what we're left with. Although parts of Powershell are open source now, I suspect the mere existence of WSL means that M…

Powershell's philosophy is the same as the one behind core-utils: Simple tools you can chain together to do complex tasks. Only it was made with 30 years of hindsight, so it actually does it much better.

Re: Shell Style Guide

#200

Earlier quoted context omitted.

>Javascript isn't the only option. It is the most popular by far and hence the "de facto" language of the web. And javascript certainly isn't "standardized" in the sense you are writing. Do you know anything about web development, browser implementation of javascript and javascript itself? Javascript is no more "standardized" than SQL is standardized. Every RDBMs implements their own flavor of SQL just like browsers…

> This is nonsense. I am very familiar with web browsers. Javascript is standardized as ECMAScript: As I said, it is standardized as SQL is "standardized", but every browser implements their own flavor just like every database server. You aren't familiar with anything. That much is obvious. > You're off your rocker. It's funny how my comments are flagged but not yours when you've been spouting nonsense. > Here is a d…

We've banned this account for repeatedly breaking the site guidelines. Would you please not create accounts to do that with?

If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future.

https://news.ycombinator.com/newsguidelines.html

Post reply on HN