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

301–310 of 336 posts

Re: Shell Style Guide

#301

Post by jessaustin »

jolmg wrote: post #251
jessaustin wrote: post #234

Earlier quoted context omitted.

Thanks for clarifying. In that case, one could imagine an env capable of parsing its single argument into the multiple intended arguments? I admit that I never dreamed that the "set" builtin would have the information about "bash -e" while the initial "OPTIONS" section did not. Why not look under the "cd", "echo", "fc", "read", or "ulimit" builtins? Somewhat helpfully, the "COMMAND EXECUTION ENVIRONMENT" section talk…

Well, to be fair, the first sentence in OPTIONS is: > All of the single-character shell options documented in the description of the set builtin command can be used as options when the shell is invoked. It's easy to miss though, when one's accustomed to quickly searching with "/". EDIT: On the imagined env, it might be possible. I wonder what aspects of shebangs are portable across the various unix derived OSs. It ma…

Haha thanks that is why I missed it.

Re: Shell Style Guide

#302

Post by jessaustin »

jolmg wrote: post #275
JdeBP wrote: post #271

Earlier quoted context omitted.

https://svnweb.freebsd.org/base?view=revision&revision=14673...

So they did it for compatibility. In the end, it seems better to take everything as 1 argument instead of simply splitting on spaces, without having support for quoting and escaping. That way you can have arbitrary code with spaces in the shebang if that's ever a good idea.

It is probably silly to dream that kernels will change their behavior, if FreeBSD had to revert such an improvement. However as you describe env is actually downstream of the kernel, so if it were improved we could envision shebangs like the following:

  #!/usr/bin/env --new-env-behavior-parse-all-args=bash -e
Some people might prefer a less verbose flag, but perhaps making it extra-yucky would improve adoption?

Re: Shell Style Guide

#303

Post by fjsolwmv »

zippitydoodah68 wrote: post #255
endtime wrote: post #204

Earlier quoted context omitted.

Exhibit A: When I joined Google Fiber, one of my first projects was converting a (POSIX) shell script that had grown to 1200 lines to Python. It became something that anyone could modify, including interns, rather than something that required at least a code review from our L7 tech lead, whose time was better spent elsewhere (he was the author and our only competent shell programmer).

That is mind blowing for me in a couple ways. * You have (at least) seven tiered support structures. * You have only one 'competent' shell programmer in your 'reachable' project scope. No wonder these types of language policies are in place.

It's been decades since "writing a 1000 line script" was best done in shell, if there ever was a time. Someone with that much experience ought to be a very senior engineer.

Re: Shell Style Guide

#304

Post by [deleted] »

Nimitz14 wrote: post #229
saagarjha wrote: post #216

Earlier quoted context omitted.

> Filenames with spaces (lol) do not happen unless you do it yourself. This is a cop out. File names can totally contain spaces, and the difference between the Bash and Python solution is that one will continue to work when a file with spaces inevitably shows up and one will fail, possibly silently.

What do you do that causes filenames to appear with spaces? And why do you not fix the cause instead of forcing yourself to deal with the possibility of a filename with a space in every possible situation?

[deleted]

Re: Shell Style Guide

#305

Post by gkya »

scruple wrote: post #203
floatboth wrote: post #150

Earlier quoted context omitted.

/bin/sh shouldn't be a C shell, it's always a POSIX-compatible shell IIRC

In the wild, hopefully not, but I do remember coming across /bin/sh executing csh in an obscure RTOS-ish / proprietary flavor of Linux that we were prototyping at a previous employer. Would've been around 2008. I can't remember the variant, but I remember being caught off-guard by it.

AFAIK /bin/sh is standard; if you cannot trust that /bin/sh is a Bourne-like sh, you might as well have to assume /usr/bin/env can not be what it was meant to be too.

Re: Shell Style Guide

#306

Post by icedchai »

zippitydoodah68 wrote: post #274
icedchai wrote: post #266

Earlier quoted context omitted.

As usual, "it depends." If you have complex logic, it's generally much cleaner to implement in python. (If you told me I had to rewrite a working Python script in shell, I'd probably think you were joking. Talk about nonsense.)

'It depends..' is a quagmire for the unwary. My route is to make a good rule about writing python with more than 'n' os. , subprocess. and *.Popen calls automatically requiring shell script counterparts in case we find your need to pythonize unsafe, unreadable and slow|broken|buggy.

There are obviously programs that are better written as a shell script, no denying it! I'm just saying use the best tool for the job. If you're writing complex logic in a shell script, you're probably barking up the wrong tree. Likewise, if all you're doing is calling external programs from python, you're probably doing it wrong.

Re: Shell Style Guide

#307

Post by gkya »

raverbashing wrote: post #170
Sir_Cmpwn wrote: post #120

Earlier quoted context omitted.

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

Default *BSD installs do not have bash, it needs to be installed (IDK what DragonFly and TrueOS do, but FreeBSD, NetBSD and OpenBSD don't ship with it). They all have it in the ports trees though. Many distros use BusyBox (IIRC Alpine is one). And AFAIK Debian base only has dash at /bin/sh.

Preferably the complexity in a shell script should be mostly handled by the programs invoked in it. All it has to provide is variables, basic control flow, subshells, and maybe some globbing.

Re: Shell Style Guide

#309

Post by gkya »

thankthunk wrote: post #42
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…

> Do not write scripts with bash. It's a bit too late for that. Bash is pretty much the de facto default shell for linux. Telling people not to use bash scripts is like telling web devs not to use javascript or OS devs not to use C. It may change in the future, but bash is so entrenched, it's going to take an extraordinary use case for people to move from bash.

Quite some people use Zsh interactively.

Re: Shell Style Guide

#310

Post by taesis »

pas wrote: post #135
taesis wrote: post #123

Earlier quoted context omitted.

Re. a recommended alternative to quick and dirty bash scripts, do you think golang would do? I've barely dabbled with the language, but its default packaging (a single, static binary) and build system (`go build x`) seem well suited to rapid setup, deployment and testing, which is presumably what you'd want in this scenario.

Many people use go for such things. I simply don't like go, it's too crude (too C), and the packaging system is. Well, it's not Cargo. But probably for deploy scripts, go with a static binary (hosted on, let's say your GitLab instance - using the GitLab HTTP API with a token to wget/curl it) is nigh unbeatable in end-to-end development and deployment time.

Aah, makes. I'm not a huge fan of it for similar reasons, but the appeal of a language that's quick, dirty, and relatively acceptable by coworkers is strong.
Post reply on HN