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

Writing Safe Shell Scripts (2019)

sipb.mit.edu

Post reply on HN
Print view View original

161–166 of 166 posts

Re: Writing Safe Shell Scripts (2019)

#161

Post by ilyash »

Hi. Author of Next Generation Shell here.

Here is my take on bash vs Python and friends. I am frustrated by both.

bash - domain specific language and huge library (CLI utilities) and lets you get the job done but not a language I would like to use (syntax, error handling, very limited structured data support).

Python - okayish as a language but doing domain specific things (working with files and processes) is so much more verbose than bash.

My solution in NGS - have a high level, modern language with the typical goodies like ... exceptions (wow, completely new concept!) and the language is still domain specific. Working with processes for example has it's own syntax and is much more concise and straightforward (stole bits from bash).

Right now the project has the language, which is useful enough to write scripts (which we do at work). Regarding contribution to the project, my idea is that as much as possible should be in NGS language (as opposed to the lower level C). The UI will be implemented completely in NGS, allowing contributing to the project using the same language you are writing your scripts in.

https://github.com/ngs-lang/ngs

As a side note, while the UI is not there yet, I do plans for it which include interaction with objects on the screen as opposed to current "here is your dump of text" situation... and in general be more considerate of the user.

https://github.com/ngs-lang/ngs/wiki/UI-Design

Re: Writing Safe Shell Scripts (2019)

#162

Post by ilyash »

heavyset_go wrote: post #30
lalaland1125 wrote: post #15

I really wonder whether there is really any point in writing shell scripts anymore. Practically every Unix/Linux box in existence has at least some version of Python 2 that can be used as a complete and total replacement. I can't think of a single situation where I would need a shell script and a Python script wouldn't be much cleaner, simpler, and more maintainable.

I've yet to find a programming language that makes I/O redirection, piping, and process substitution[1] as easy as Bash does. Process substitution is where the shell really shines, in my opinion. Bash, and Bash-like shells, are literally everywhere. I have to be wary about what Python 3 features I use, and if there will even be a Python interpreter available. My OpenWRT router has a Bash shell, but I don't care to in…

> I've yet to find a programming language that makes I/O redirection, piping, and process substitution[1] as easy as Bash does.

Next Generation Shell - mostly there. If something of the above is missing - it's a bug and you are welcome to open an issue. I'm the author.

https://github.com/ngs-lang/ngs

Re: Writing Safe Shell Scripts (2019)

#163

Post by heavyset_go »

ilyash wrote: post #162
heavyset_go wrote: post #30

Earlier quoted context omitted.

I've yet to find a programming language that makes I/O redirection, piping, and process substitution[1] as easy as Bash does. Process substitution is where the shell really shines, in my opinion. Bash, and Bash-like shells, are literally everywhere. I have to be wary about what Python 3 features I use, and if there will even be a Python interpreter available. My OpenWRT router has a Bash shell, but I don't care to in…

> I've yet to find a programming language that makes I/O redirection, piping, and process substitution[1] as easy as Bash does. Next Generation Shell - mostly there. If something of the above is missing - it's a bug and you are welcome to open an issue. I'm the author. https://github.com/ngs-lang/ngs

I like this a lot. Definitely very cool, and I plan on giving it a shot when I have some time.

Just curious, but how would one do process substitution with NGS?

Re: Writing Safe Shell Scripts (2019)

#164

Post by seorphates »

clarry wrote: post #90
seorphates wrote: post #86

Earlier quoted context omitted.

Ok, "garbage" may have been harsh but how about a fun example? Try this with and without -e #!/usr/bin/env bash bell=`tput bel` tock='Blastoff!' do_ring() { if [ "$1" ]; then # true echo -n $bell; sleep 0.1 echo -n $bell; sleep 0.1 echo -n $bell; sleep 0.1 echo $tock else echo -n $bell; sleep 0.1 fi } i=3 while [ "$i" -ge "0" ]; do if [ $i = 0 ]; then sleep 0.5 echo ok else echo $i $bell sleep 0.5 fi i=`expr $i - 1`…

That's why nobody uses expr for arithmetic. But yes, it is annoying that -e breaks some habits that work fine without it.

I can appreciate the quip, especially given my curmundgeonly entry. But the point remains. The shell needs to be able to call any command on the system reliably. Even aged old counting methods. At no point in that loop would the expr subprocess return other than zero. Try to break out of that loop with that bash switch.

One should not rely on these magics, the ones that alter runtime behaviors, without truly understanding what you're after and what you're writing. Or mostly understand. They're fine and good if you have narrow routines with a very strict focus - "I'm in, I'm out, bang."

The best switches available to the shell without a bunch of feature and package and library this or that bloat are exactly

  -x
  -n
That's all that you need to ensure that your scripting is what you need it to be. Introduce the magic after you've written the thing. When it's ready and it passes your tests then test it again.

Every single utility and package on that system is at your fingertips. Demand accuracy. I do.

Re: Writing Safe Shell Scripts (2019)

#165

Post by urda »

urda wrote: post #98
mekster wrote: post #2

Make sure to have ShellCheck either integrated in your editor or run it before executing. It really tells many of the rules you're supposed to abide by and helps you write cleaner shell script. https://github.com/koalaman/shellcheck

Quick reminder that ShellCheck is licensed under the strict GNU GPL 3.0 license. For many professionals your employer will often block / avoid GPL code, tools, and libraries.

I'm disappointed in you HN. The downvoting behavior over just discussing the facts of a codebase or industry is unacceptable and unbecoming. Your feelings of how software licensing should be does not matter here.

Re: Writing Safe Shell Scripts (2019)

#166

Post by bradknowles »

ahnick wrote: post #158
bradknowles wrote: post #155

Earlier quoted context omitted.

Apple is strongly anti-GPL. And they’re pretty open about that. Most companies that are anti-GPL aren’t so open about it.

I get that Apple doesn't want GPL code included in their software, but their engineers can still use GPL tools without fear of opening up their proprietary code. I know of plenty of companies where you can not INCLUDE GPL code in the software the company makes, but I don't know of any company that says you can not USE any GPL software to do your job. Those are two different things.

For the six month contract I did at Apple, they were violently opposed to using any GPL software in any way, shape, or form.

Just because you can do something, doesn't necessarily mean you should. That rule applies to the implementation of corporate policies regarding licensing, too.

Post reply on HN