The first piece of advice, "Don't", is the best. "shellcheck myscript.sh" should return a fatal error if the shell script file you're checking exists, and "shellcheck -f myscript.sh" should fix your shell script by removing it.
Writing Safe Shell Scripts (2019)
131–140 of 166 posts
Re: Writing Safe Shell Scripts (2019)
#132Earlier quoted context omitted.
What’s wrong with python?
Feels like the wrong tool for the job with the whole virtual environment that has to be brought up. Performance for shell scripts isn't super critical in my eyes but the startup time of python feels too much for something you might want to run in an inner-loop from find or something. Not sure if python IO performance is suitable for shell scripts either. Also isn't nearly as universal as shell-scripts nor something y…
You don’t need a virtual env.
I probably wouldn’t wrap GNU find and python, I’d just walk the directory tree in python and use regex.
IO is suitable for everyday tasks and shouldn’t be an issue in Python anyway, if it is either you’re doing it wrong or your shell script should be written in C and not touch interpreted/bytecode compiled languages at all.
Re: Writing Safe Shell Scripts (2019)
#133On set -e:
This is like adding a setting to your Java or Python program to immediately exit if any method call throws any kind of exception, with no possibility of catching and handling that exception.
This does not seem to be a smart thing to do as compared to checking return codes, etc.
Every script I've seen with set -e has been buggier than without it.
The main problem with scripts is that they often do not go through a normal software review and testing process.
Re: Writing Safe Shell Scripts (2019)
#134I'm not sure I'm comfortable with python for a typical shell script. But then again, what alternatives exist? I've been thinking that we are kind of stuck with it. Much like javascript. So, we could go the route of typescript and have a translation layer and outputting shell scripts. I actually think that could work quite well from a technical standpoint. A big part of shellscripts though is having the source availab…
> I'm not sure I'm comfortable with python for a typical shell script. But then again, what alternatives exist?
perl still exists, and is a wonderful alternative to python for "shell scripts plus". The syntax should be at least vaguely familiar to anyone who has touched bash, awk, sed, etc.
Re: Writing Safe Shell Scripts (2019)
#135Earlier quoted context omitted.
Feels like the wrong tool for the job with the whole virtual environment that has to be brought up. Performance for shell scripts isn't super critical in my eyes but the startup time of python feels too much for something you might want to run in an inner-loop from find or something. Not sure if python IO performance is suitable for shell scripts either. Also isn't nearly as universal as shell-scripts nor something y…
You don’t need a virtual env. I probably wouldn’t wrap GNU find and python, I’d just walk the directory tree in python and use regex. IO is suitable for everyday tasks and shouldn’t be an issue in Python anyway, if it is either you’re doing it wrong or your shell script should be written in C and not touch interpreted/bytecode compiled languages at all.
Me neither, but a big point of shell scripts is that they are the same commands you'd run on the shell itself.
And there are lots of really optimized tools that are as quick as can be, throwing them out is a hefty price to pay.
Re: Writing Safe Shell Scripts (2019)
#136Earlier quoted context omitted.
PowerShell, mostly because PowerShell was designed as a mashup of Bash and C#.... And it's kind of a trainwreck in a lot of ways. It really feels like piping and easy process invocation and compile-time directory awareness wouldn't be massively onerous to add to an existing full-featured programming language so you wouldn't have to sacrifice a good type system and powerful syntax when you want to do scripty things.
Some of the features of PowerShell seem really enticing, and I wish they would make their way over to Unix-like shells. Unfortunately, I don't know how much utility I'd get out of PowerShell on Linux, so I haven't tried it. edit: your comment inspired me so I installed PowerShell via Snap and am going to give it a go on Linux.
To me PowerShell mixes easy access to command-line tools and higher-order object-oriented map/filter style functions. The mix between Unix-style piping from command-line tools and modern object-y mapping and filtering can feel like a dream.
That's the good part. The bad part is that it's easily one of the wartiest languages I've ever used, especially as a young language it's really got an inexcusable amount of legacy problems.
A colleague of mine (who also uses it heavily) says "two Googles per line".
Just to get sane parameter and variable checking you have to throw up a bunch of attributes and set a bunch of flags.
Be sure to set up strict mode, use cmdletbinding on your parameter blocks, and set ErrorActionPreference to "stop" in every script you write.
That and the quality of many of the first-party official PowerShell modules is appallingly low by Microsoft standards. The good side is that the .NET framework is accessible so whenever the PowerShell module is failing you, you can drop down into leveraging raw c#-style assemblies, which are much higher quality but they speak PowerShell with a very thick accent.
But I'm using it on Windows, YMMV on Linux.
I'm infatuated with the concept, but the implementation leaves a lot to be desired.
Re: Writing Safe Shell Scripts (2019)
#137Earlier quoted context omitted.
PowerShell, mostly because PowerShell was designed as a mashup of Bash and C#.... And it's kind of a trainwreck in a lot of ways. It really feels like piping and easy process invocation and compile-time directory awareness wouldn't be massively onerous to add to an existing full-featured programming language so you wouldn't have to sacrifice a good type system and powerful syntax when you want to do scripty things.
As I understand it, PowerShell came about because porting the standard Linux/Unix utilities to Windows didn't work out. PowerShell meets both requirements as it's tuned for the Windows environment, but can still play nicely with the rest of the world. Of course, now that WSL is a thing, it's a real question why someone would want to use PS unless they had no other options. https://www.heavybit.com/library/podcasts/to…
>Of course, now that WSL is a thing, it's a real question why someone would want to use PS unless they had no other options.
I use it because I only have to learn one tool, and not a ton of different ones with different UX.
The 'language' is sane, at least to me, as it's object oriented doesn't revolve around parsing strings.
Re: Writing Safe Shell Scripts (2019)
#138Earlier quoted context omitted.
FWIW I think ShellCheck is great and the state of the art, but Oil is partly (negatively) inspired by ShellCheck :) Somebody integrated ShellCheck into Google's code review system about four years ago, right before I left. So the result was that every code review I sent with a shell script was filled with red squigglies -- "add double quotes here". Most code reviewers don't really know shell, but if they see red squi…
It's a burden to you only because you're used to not putting quotes in some cases. But to some of us who always put the quotes, it's not really about that at all, and it's not a subjective issue - missing them is literally wrong . It's like sprinkling random .split(" ") calls in your Python code for no reason, which you'd (hopefully?) never do. And when something is semantically so wrong, the elegance of its syntax c…
Quotes are just a tool, not a religious requisite. Chubot is talking from experience, and he is right. Putting quotes on all shell expressions is a burden, because it's more keystrokes, and more characters on the display which make the source on display disorienting. When you use shell every day, you know where the quotes are needed and where they are just a noise. Use a tool - when it's needed.
Re: Writing Safe Shell Scripts (2019)
#139I'm not sure I'm comfortable with python for a typical shell script. But then again, what alternatives exist? I've been thinking that we are kind of stuck with it. Much like javascript. So, we could go the route of typescript and have a translation layer and outputting shell scripts. I actually think that could work quite well from a technical standpoint. A big part of shellscripts though is having the source availab…
What’s wrong with python?
It's too high level for a shell - the unix concepts are too many keystrokes and modules away in python. Also, bad performance.
Re: Writing Safe Shell Scripts (2019)
#140I 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.
> Practically every Unix/Linux box in existence has at least some version of Python If we understand "box" as "environment", in general, and not literally a physical or virtual machine... Not really. E.g. see: every clean Ubuntu Docker container. They don't have Python, nor should have to include it by default. And if you are going to do something like this: apt-get update && apt-get install -y stuff wget https://fil…
> Python API for Apt
There seems to be something very wrong with this expression. Why would one need API for apt? It's a command-line tool.