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

Shell Style Guide

google.github.io

Post reply on HN
Print view View original

161–170 of 336 posts

Re: Shell Style Guide

#161

Post by nameless912 »

gre wrote: post #127

> If performance matters, use something other than shell. I wrote a script that wrapped compiler calls to make dummy output files to debug a huge compilation. Since startup time was the most important metric, bash actually had by far the best performance.

People rag on bash a lot, but it now forms the core of a major deployment system I built at work. I'm not happy that it's in bash, but every other solution was worse, and it calls out to other tools (e.g. Ansible and Terraform) when they're appropriate.

People have forgotten the subtle art of realizing what tool is best for the job. If all you're doing is stitching together other tools and doing some logging, bash is hard to beat.

Re: Shell Style Guide

#162

Post by [deleted] »

mitchty wrote: post #137
nvarsj wrote: 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.

> 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. Its not a ruby thing, its the way you're supposed to write portable scripts where the location of the executable might not be predetermined. Lets say you're on a distribution where bash is in /us…

[deleted]

Re: Shell Style Guide

#163

Post by sanderjd »

bitlax wrote: post #49
tootie wrote: post #18

I absolutely hate coding in bash or looking at bash or suddenly being in Windows and being up a tree because bash isn't supported well (it is now if you install WSL). I only use bash to set environment variables and maybe string together 2 or 3 build commands. If I need so much as an if statement, I'm going to switch to a real programming language.

This document agrees with you. - If you find you need to use arrays for anything more than assignment of ${PIPESTATUS}, you should use Python. - If you are writing a script that is more than 100 lines long, you should probably be writing it in Python instead. Bear in mind that scripts grow. Rewrite your script in another language early to avoid a time-consuming rewrite at a later date.

I really don't understand the "switch to Python" thing. Bash scripts are good for calling sequences of command line programs. That is not particularly convenient in Python.

Re: Shell Style Guide

#164

Post by chrisfinazzo »

jve wrote: post #107
chrisfinazzo wrote: post #58

Earlier quoted context omitted.

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…

> Historically, PowerShell was supposed to be a replacement for cmd.exe and roughly equivalent to bash What? PowerShell has radically different ideology. Plus it is super consistent (helps discover commands), extensible and works with objects rather plain strings, use .NET functions or call custom .dll functions... > They tried early on to port some of the UNIX & Linux tools to Windows and it didn't fly Actually they…

There is an episode of the "To Be Continuous" podcast with Jeff Snover (PS's inventor) that gets into this a bit more. Because of the difference in philosophy, a straight port to Windows didn't work well.

Basically, text files (UNIX) v structured data from API's (Windows), thus PowerShell was born.

https://www.heavybit.com/library/podcasts/to-be-continuous/e...

Re: Shell Style Guide

#165

Post by pas »

chronial wrote: post #155
pas wrote: post #125

Earlier quoted context omitted.

> trap I don't have more faith in Python's except than in Bash's trap. If you use 3rd party code or a subprocess, then both are pretty weak compared to something kernel enforced. > makes it massively easier to handle errors and give decent diagnostics to the user. I don't really find that. You have to fight for input/output for subprocesses in Python. Sure, logging is easier in Python/perl/PHP/whatever, than in Bash,…

> 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.

Re: Shell Style Guide

#166

Post by pstuart »

no_wizard wrote: post #156

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.

Re: Shell Style Guide

#167

Post by thankthunk »

Sir_Cmpwn wrote: post #78
thankthunk wrote: post #74

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. 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 direct quote from your comment:

That's right. It's a bit late to tell users to stop using bash. What's so confusing about that? My point is that a "strong use case" has to be introduced, not telling people to switch? Once again, if you learned to read rather than fanboying, you would have caught onto it. My point is that telling people to change isn't going to work when something is established. There has to be a serious use case to incentivize people to switch. Okay? No different than switching to powershell from cmd in windows or to python from perl in linux.

>Derp, I meant K&R C or pre-ANSI C. My mistake.

"Derp"? All your comments were "derp". But this being Hacker news, people providing factual and thorough responses get penalized why people spouting nonsense like "that is whack or "you're off your rocker" doesn't.

Maybe you should learn about C, Javascript, web development, browsers, internet or anything before spouting nonsense. Okay? And maybe you learned to read rather than jumping to conclusions. Because every single response of yours has been a result of you misreading my comment. Good day.

Re: Shell Style Guide

#168

Post by chubot »

reacweb wrote: post #43
Sir_Cmpwn wrote: post #3

>Bash is the only shell scripting language permitted for executables. Whelp, wrong right off the bat. I'm gonna get down my my knees here and beg everyone reading: use POSIX shell. Do not write scripts with bash. Do not write scripts with zsh. Do not write scripts with fish. Use POSIX shell. sh has a really bad interactive mode (so does bash), so I'm not gonna give anyone a hard time for using another shell as their…

I have the opposite opinion. I have seen developers proudly putting /bin/sh instead of /bin/bash, without any other shell to test. When the script was run on ubuntu instead of redhat, this called dash and we discovered that the script was finally not compliant on subtle details. Writing POSIX compliant scripts is harder. Where is the reward when bash is present (almost) everywhere?

Yes exactly, I had this experience and wrote about it here:

http://www.oilshell.org/blog/2018/01/28.html#limit-to-posix

Re: Shell Style Guide

#169

Post by mattnewton »

laurent123456 wrote: post #92
pas wrote: post #81

Earlier quoted context omitted.

Exchanging Bash for Python is a folly. Python seems to handle complexity better, but only on the surface. (Basically Python has nice data structures, great string formatting, and .. that's it.) Setting up the Python environment requires something, because Python comes in many flavors (2 vs 3, system installed, user installed, /usr/local) and there are a bunch of factors (pip, pyenv, pipenv, PYTHONPATH, current direct…

I had some success with Node.js (though it was in a Node-based project to begin with). I haven't tried piping commands, but to run a bunch of commands and then have all the logic in JavaScript it's quite convenient. Here's an example that builds a React Native app, while updating version numbers and Git tags: https://github.com/laurent22/joplin/blob/master/Tools/releas...

My main problem with scripting in Node vs python is the event loop gets in your way when just trying to write a quick and dirty sequence of steps. Sure you can use async await but now you are transpiling your script.. seems easier to just bang it out in python.

I love Node but I use it for backend where the event-loop model is useful.

Re: Shell Style Guide

#170

Post by raverbashing »

Sir_Cmpwn wrote: post #120
raverbashing wrote: post #113

Earlier quoted context omitted.

Nobody cares about non-bash shells if they're not dealing with legacy systems. (And if you are, you have bigger problems)

Wrong. *BSD are not legacy systems, and many Linux installs don't have Bash. On top of that, new systems can't really implement Bash (because bash is defined by the implementation) but could easily implement POSIX sh (because POSIX sh is defined by the standard).

Agreed with BSD, but they usually have bash. (And you usually can compile it for your legacy application - I have done this)

Though I agree that if you're doing something bash specific you're most likely doing something that would be done better using Python/Perl/Ruby, etc

Post reply on HN