I am serious.
I have decided for my own efforts to use python for any kind of command line script and I’m always glad I did.
I do agree though that if you need extensive massaging of output or arguments, python can help and make the whole thing easier.
Available as `python3-sh` in Ubuntu.
I've been resisting learning (any more) bash for a while now, but I think I'm going to have to. This looks like it could reduce some of my terror at the insanities of shell scripts (why does one even need two quote characters that do different things?)
A couple recommendations that make bash a much saner and avoid entire classes of problems:
First, whenever you are expanding a list of args, use "$@"! That exact four character sequence expands to the properly quoted positional params ("$1" "$2" ...) with any necessary escaping included so each param expands as a single word. Almost all of the problems you've probably heard about bash "not handling spaces properly" or otherwise having problems with whitespace or strange characters in filenames are fixed by using "$@". If you're using arrays/hashes, you can get the same effect using "${somearrayorhash[@]}" (quotes included, just like "$@"). Removing the quotes or using the tradition $* is almost always a bug.
Second, always use explicit quotes/brackets! Forget that they were ever optional. Using "$@" fixes most of the whitespace-in-filename problems; expanding your variables with explicit quotes fixes the rest. Assuming these:
showargs() {
echo "$# args"
for i in "$@" ; do
echo "arg[${i}]"
done
}
declare -- name="filename with spaces\\!.txt"
declare -A h='([a]="b c" [foo]="'\''bar'\'' \"baz\" qu*x" )'
showargs $name
# 3 args
# arg[filename]
# arg[with]
# arg[spaces\!.txt]
showargs ${h[*]} # or ${h[@]}
# 7 args
# arg[b]
# arg[c]
# arg['bar']
# arg["baz"]
# arg[qu*x]
showargs "${name}"
# 1 args
# arg[filename with spaces\!.txt]
showargs "${h[@]}"
# 2 args
# arg[b c d e]
# arg['bar' "baz" qu*x]
$ echo ‘pwd’
$ echo “pwd” $ echo $(pwd)
Edited to add: shellcheck [0] will flag the back quote usage if you're writing a bash script instead of a sh script.
`Thank you`!
I start to get the feeling that if you feel the need for shell scripts, it might be wise to pause and wonder of this is really the right approach long-term. Especially if you feel the need to put it in git or something.
My experience is that there are often I need to put in some checks for safety and before I know it, you create a mess of grep awk cut sed and you wish you started out with python.
Are you really that much in a hurry or do you have the time to calmly spend a little bit more time to ‘do it right?’
Along similar lines bash's syntax is incredibly streamlined for composing standalone scripts and programs through pipes. A simple bash one-liner like the below would be much more awkward to write in python:
> diff <(netcat $server | grep town | sed 's/street/St' | cut -f 3 | head -n 5) <(cat ./$(psql $query).dat)
It is all about context to me. A shell oneliner is not something I would replace with python but as soon as you start up an editor, think again I would say
Eventually I realised it was a lost cause and really you just shouldn't use shell scripts for anything that you want to be reliable above a trivial level of complexity.
That was with PowerShell, but I wouldn't be surprised if the same applies to bash as well.
Bash people are the worst when they switch, since they keep the same mentality and continue parsing strings or use other bashizms.
See my answer above also.
Powershell is on another plane, more like Python and less like bash shell scripting.
I used Powershell and Pester a lot and it worked great.
Bash becomes a mess of cat grep sed awk cut
We also test REST backend in PowerShell using Pester and home made Posh rest client.
PowerShell is preferred in this house because
a) you can run it on any Windows OS on the spot and modify it in ad hoc manner, you can even debug it with breakpoints etc easily. Also our Linux machines have it so it is unifying admin interface.
b) its powerful, you can do anything in it with few lines of code (one case: we did 10 million SOAP requests using certificate per day for entire country)
c) many Windows tools use it like SqlServer, IIS etc. which makes management way easier - for example we use [1] to install sql server on all dev/prod machines or use [2] to monitor all our servers or use [3] to send CI metrics to influx (all those are just minor samples, we have bunch of stuff like that)
d) we find it way easier to keep CI/CD vars in PowerShell hashtables then in yaml, so our yaml fiels are one liners and everything works locally.
e) Python, ruby and friends are NOT designed for shell work. Its akward, unfriendly and most of all not there on Windows OTB.
---
[1] https://github.com/majkinetor/Install-SqlServer
> I am not that into the way MS is doing the winget thing,
That is years away IMO, no scripting there too, and it moves like a snail. I would really be embarrassed if I were leading that team.
> I see a lot of manual scripts for installing things on Windows CI systems
Yeah, most people suck, like their scripts :-) There is literary 0 chance for you to make reliable installation script in general that works in any context.
> I really like chocolatey but I am worried it will disappear soon.
Just use it. I don't work for them. I maintain core team repo [2]. Its great tool now. What will happen tomorrow nobody knows but like I said, you have escape plan and even if they go down your CI will still work for many years if you set it up properly.
---
[1] https://gist.github.com/majkinetor/a700c70b8847b29ebb1c918d4...
[2] https://github.com/chocolatey-community/chocolatey-coreteamp...
[3] https://github.com/majkinetor/au
[4] https://github.com/majkinetor/au-packages/tags
[5] https://github.com/chocolatey-community/chocolatey-coreteamp...
Powershell is so much powerfull, I’ve written a ton of code in that and also used Pester for unit testing.
Entirely different world compared to shell scripting.