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

261–270 of 336 posts

Re: Shell Style Guide

#261

Post by zippitydoodah68 »

icedchai wrote: post #241
sanderjd wrote: post #163

Earlier quoted context omitted.

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.

It's perfectly convenient. The subprocess module works well enough for such things. Or even the old os.system.

Perfectly convenient, safe and fast. Pick any two. https://docs.python.org/2/library/subprocess.html

I've told developers that if I catch them writing shell scripts in python they must commit a shell script doing the same set of operations. 2x the work usually dissuades from this type of nonsense.

Re: Shell Style Guide

#262

Post by jolmg »

JdeBP wrote: post #257
jolmg wrote: post #222

Earlier quoted context omitted.

It's not because of env. It's just that shebangs are limited to passing one optional argument to the executable specified. The way they're parsed is the executable path, and if there's a space, then the rest of the line (including any additional spaces) is interpreted as 1 argument to the executable. EDIT: -e causes bash to exit on the first command that returns with an error (returns with a non-zero return code). It…

Interestingly, FreeBSD used to allow for multiple arguments.

Do you know why they stopped?

Re: Shell Style Guide

#263

Post by JdeBP »

susam wrote: post #93
Sir_Cmpwn wrote: post #46

Earlier quoted context omitted.

>Where is the reward when bash is present (almost) everywhere? It's really not. It's only present on some desktop Linux distributions. It's not present on almost any other OS or anywhere in the embedded space. POSIX shell, on the other hand, is everywhere.

> POSIX shell, on the other hand, is everywhere. Indeed! The significance of this, I believe, is underappreciated. During 2008-2015, when I used to work for a network security company, we had a file transfer script[1] for Unix and Linux systems. It was written entirely as a shell script. It began as a simple wrapper around the scp and sftp commands for which a shell script was appropriate. The fact that every Unix an…

Note that there are several variants of the Korn shell. And there are even more shells than that.

You can test ksh93 and the MirOS Korn shell on Debian. For the Heirloom Bourne shell, though, look to FreeBSD, which has everything except the Watanabe shell.

* https://svnweb.freebsd.org/ports/head/shells/heirloom-sh/

* https://svnweb.freebsd.org/ports/head/shells/pdksh/

* https://svnweb.freebsd.org/ports/head/shells/ksh93/

* https://svnweb.freebsd.org/ports/head/shells/mksh/

* https://svnweb.freebsd.org/ports/head/shells/oksh/

* https://svnweb.freebsd.org/ports/head/shells/dash/

* https://www.freebsd.org/ports/shells.html

I appreciate what this sort of thing involves, as you can infer. (-:

* https://unix.stackexchange.com/a/434839/5132

Re: Shell Style Guide

#264

Post by oblio »

blacksqr wrote: post #206
oblio wrote: post #175

Earlier quoted context omitted.

Yeah, but Tcl is old and quite crufty. The docs are a mess, everything is a string, a lot of concepts it uses are not very familiar and/or mainstream (upvar?). A modern take on Tcl is what we need, in my opinion. Surely we should be able to build something nicer 30 years after the first release of Tcl.

The modern take on Tcl arrived almost 20 years ago, when "everything is a string" turned into "everything is a typed object with a string representation". The docs are clear and complete, and the concepts it uses make it a powerful and elegant tool.

The docs are clear and complete?!?

Has something changed suddenly in the last 5 years? Yes, the docs had a decent API reference but everything slightly higher up than "what parameters this command has" was on that wiki with comments from 2004 marked as out of date by out of date comments from 2007...

Re: Shell Style Guide

#265

Post by oblio »

JepZ wrote: post #196
oblio wrote: post #33

Earlier quoted context omitted.

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.

Nothing will replace bash within my lifetime. Zsh didn't even though it was superior for over a decade.

Heck, Microsoft barely managed to supplant cmd 1-2 years ago, and that's in a non-standard, proprietary environment by what is arguably the biggest commercial platform maker in the world.

Re: Shell Style Guide

#266

Post by icedchai »

zippitydoodah68 wrote: post #261
icedchai wrote: post #241

Earlier quoted context omitted.

It's perfectly convenient. The subprocess module works well enough for such things. Or even the old os.system.

Perfectly convenient, safe and fast. Pick any two. https://docs.python.org/2/library/subprocess.html I've told developers that if I catch them writing shell scripts in python they must commit a shell script doing the same set of operations. 2x the work usually dissuades from this type of nonsense.

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

Re: Shell Style Guide

#267

Post by JdeBP »

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.

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

You don't know your history. Exactly such a move has already happened once, a decade ago. And it was a success.

* https://lists.debian.org/debian-release/2007/07/msg00027.htm...

* http://initscripts-ng.alioth.debian.org/soc2006-bootsystem/b...

* https://wiki.debian.org/BootProcessSpeedup#Using_a_faster_sy...

Re: Shell Style Guide

#269

Post by amptorn »

pstuart wrote: post #166
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.

I enjoy the section of the Advanced Bash-Scripting Guide which explains how Bash has sparse arrays which "are useful in spreadsheet-processing software".[0] Because someone out there is apparently writing spreadsheet-processing software in Bash?

[0] http://tldp.org/LDP/abs/html/arrays.html

Re: Shell Style Guide

#270

Post by JdeBP »

hrktb wrote: post #157
icebraining wrote: post #71

Earlier quoted context omitted.

one character sequence is interpreted as EOF I know this is just an example, but how would that happen?

You can hit EOF or EOT in a stream of UTF-8 or other multi-byte encoding as part of a character. There must be ways to have it handled through something that understands character encodings and workaround the issue, but I know that dumb shell piping will fumble on those.

    % printf '\x04\necho EOT is not EOF in a pipe.\n' | bash
    bash: line 1: $'\004': command not found
    EOT is not EOF in a pipe.
    %
Pipes do not contain line disciplines and thus do not do special character processing.
Post reply on HN