A high-level language for scripting?

[-]

The technically most impressive sysadmins I know are fluent in Perl. Probably because they are of the old school where efficiency mattered and on the whole people wrote things better. On the flip side, the same folks think systemd is the devil, containers are a flash in the pan, and generally tend to be luddites. With all things, the middle ground is usually the best, imo

[-]

aioeu@reddit

There's dozens of us!

[-]

bigredradio@reddit

Maybe enough for a foursome of Perl golf.

[-]

tanjera@reddit

I love Perl for scripting! It just works.

[-]

Lammtarra95@reddit

Nobody uses Perl no more?

Soon I shall be taking my perl books to the ~~tip~~ recycling centre. I occasionally use a one-liner but nothing complicated enough to be called programming. (And if I did, everything can be looked up online anyway.)

[-]

orev@reddit

Those might be collectors items these days.

[-]

FarToe1@reddit

They're almost certainly good for modern perl on a modern operating system, even of they're from the 90s.

[-]

BumseBBine@reddit

The only persons I know that use perl are 30+. The problem is there objectively better and easier languages to learn today. My boss knows the ins and outs of perl and it's impressive how he does XYZ in one line of code while I in python need 10-20 lines. But it's barely readable for someone who isn't fluent in Bash and Perl (syntax is really similar sometimes)

[-]

FarToe1@reddit

Objectively better? Not by all margins.

If you're a sysadmin who needs to work on hundreds or thousands of linux machines of various distributions, and where bash won't cut it - perl is the only sane choice.

Nothing else is installed by default everywhere already. Nothing else will continue to work years or decades into the future with no upkeep. (I have perl scripts I wrote back in the 90s that are still running away happily on modern OSs).

Sure, for many choices perl is wrong. But in my world, if you don't do perl, you're doing things the hard way.

It's got a bad reputation for difficulty, so people avoid it, which probably confirms your 30+ claim. It's totally unwarranted though.

[-]

orev@reddit

Perl is expressive enough that the true nature of the programmer is revealed, so if they're making things hard to read, it's because they're a bad programmer. You can easily write Perl programs that are easy to read if you choose to.

[-]

g_rich@reddit

I’m well over 30 and have managed to stay away from Perl (other than a brief stint working with Bugzilla); I was fortunate enough to come into thing when Python was on the upswing.

[-]

H3rbert_K0rnfeld@reddit

Wait till you see sed and awk

[-]

InvestmentLoose5714@reddit

I would use ses and awk before perl anytime.

[-]

derprondo@reddit

Even 10 years ago I interviewed someone and their take home programming assignment that could be done in any language and they submitted perl. Only I hadn't seen perl in so long that I stared at the code with no file extension for an embarrassingly long time before I realized what it was.

Anyway, these days Python is ubiquitous and everyone knows it.

[-]

derprondo@reddit

I don't know what the downvotes are about, I learned perl in college in the late 90s/early 2000s and past ~2008 I never used it again.

[-]

procsysnet@reddit

I still do from time to time and I fall in love every time I use it. It's a cool, expressive, delightfully unhinged, regex-fueled and astonishingly sharp-edged way of shooting myself in the foot and antagonize my coworkers. I love it

[-]

CommercialMonth3640@reddit

In the AI era, the only programming language you can use is English, buddy.

[-]

rairock@reddit

I'd never use C# for scripting. I think it's just overcomplicating things unnecessarily. Having Bash, PowerShell, Python and Go, at least in my case, you can cover everything you need to do in the world. I can't imagine a use case where you would need something not included on these 4.

[-]

kentrak@reddit

Bash:

Pros: (Almost) universally available by default(looking at you BSDs), one of the easiest ways to tie in random command line programs.
Cons: lots of gotchas onthe correct way to deal with error handling and dealing with conditions. API integration library support will be a weird hodge podge of stuff.
Recommendation: Use shellcheck or equivalent (and anything else you can find) to mitigate the many pitfalls in using it in a robust manner.

Perl:

Pros: Very robust, backwards compatibility is second to none. You can run a script written 20+ years ago and if it doesn't rely on modules (or the modules haven't changes their API, which is also somewhat likely to be true), then it will just work. Module ecosystem works much better than a lot of alternatives.
Cons: Backwards compatibility is a double edged sword. Some nicer features of languages are missing or added in limited fashion. There is also hidden complexity, in that Perl appears to be very similar to other languages but is quite different in ways not immediately apparent that cause people confusion (read up on evaluation context and perl being operator oriented as shorthands for what I'm talking at (as an almost 30+ year primary Perl dev). Some lacking libraries at this point for services that put out official versions, because they often don't bother with Perl anymore. Maybe less of an issue now in the age of AI where you can just tell it to make you one?
Recommendation: Read something like Perl Best Practices or Modern Perl. Both quite old at this point... but it helps avoid newbie problems of write-only code you can't understand later, which is a particular problem until you understand what you're doing.

Python:

Pros: Everyone knows it, every company makes sure to supply a python library for their service if they supply anything, plenty of people to get help from. Fairly opinionated so often more obvious how you should do something.
Cons: Can be a bit verbose or take up more room so your scripts will be longer. Only a problem when you get the medium complexity and less fits on a screen at a time. Has regressed somewhat on idea that there's one right way to do it in chasing developer features, so slightly more complex than it started out at this point.
Recommendations: Very good glue language between many different modules, probably better than that at Perl given the module ecosystems.

Go:

Pro: Walks the line between compiled languages and scripting languages. Can be goo dif you need to ship your code/scripts to different systens and makingg sure they have a standard environment and libraries and/or language modules is hard or impossible, since you compile and ship binaries
Cons: Harder to look at the code on the system to figure out what it's doing, since souce code is often not on those systems, so you need to know where and how to access source. Not quite as easy to whip out a script as an interpreted language both because it's compiled and because it's statically typed.
Recommendations: Have good source control. It's good for every language, essential for a compiled one.

I imagine C# is somewhat similar to Go but there's still a runtime to make sure is present, and I can't comment on PowerShell but it seems like an interesting language with how it passes structured data between shell components. Windows Batch? It will work in a pinch, and it's always present, but it seems fairly limiting.

[-]

NL_Gray-Fox@reddit

If you hand me a bash, batch, powershell or python script, I can usually tell if it's safe to run. if you hand me something compiled (c#, Java, ...) I have no idea what it will do until I run it (even then you technically don't know).

e.g. uncompiled languages can be read by humans and are (in my opinion) therefor safer, plus if it doesn't work on my system because you hardcoded something that is somewhere else on my machine I can easily change it without getting the source code.

obviously there (are/can be) speed tradeoffs.

[-]

eman0821@reddit

All languages are high level regardless if it's a scripting language or a object oriented language. Java, C/C++, C#, Rust, GO are rarely used for scripting as I don't know anyone that does in the real world. Bash, Perl, Python and configuration management tools such as Ansible, Puppet and Chef is what you typically see in Linux environments.

[-]

redundant78@reddit

C is definitely not high level, it's about as close to the metal as you can get without writing assembly. And Go is used for CLI tools and scripting-style tasks all the time these days - tons of devops tooling is written in it precisely because it compiles to a single binary with no runtime dependencies.

[-]

fubes2000@reddit

Specifically bash can do some really impressive things that even high-level languages struggle to do simply or efficiently because of shell features like pipes, a rich ecosystem of GNU utilities, as well as being able to invoke any program with a robust command line interface.

Want to run some basic filters/analytics on millions of lines of log files? sed, grep, and awk will blaze through it in a minute. Sort those millions of lines? sort does it efficiently. Have a list of work that needs to be done? xargs will get it. Need to parallelize that? xargs -P or parallel will do it.

[-]

adjunct_@reddit

Object oriented

[-]

aenae@reddit

You still need bash to run your script. Might as well write it in bash if it is a simple one

[-]

fathed@reddit

Why?

Powershell is basically c# in a shell, you can also directly compile and run a c# script with one line.

Why people still suggest a non-object oriented shell language will never stop baffling me.

For the actual op, python is fine, as long as you are just running scripts, but if you also want your scripting environment to also work as a shell, powershell wins in my opinion.

[-]

aenae@reddit

Because we're not going to spend an extra 1GB to include powershell in our containers.

[-]

fathed@reddit

Powershell isn't the only choice.

I do find it hilarious that you used grep as the example, as avoiding regular expressions as a solution is easier with objects.

[-]

chocopudding17@reddit

Who mentioned containers? Like, yeah, you should basically never have more than just busybox in a container at the most. But the OP seems like a very general question. And I agree with fathed's appreciation of PowerShell, and that non-object oriented shells are broadly inferior. Mind you, I use bash for plenty of things. But that's mostly for inertia and historical reasons than it actually being better. If I had a fleet of servers where I could have PowerShell universally installed, I'd probably only write PowerShell.

[-]

franktheworm@reddit

While I agree with not adding PowerShell, that's more of a straw man than that character from the wizard of oz. By that logic you should be using a statically linked, compiled language like Go etc to cut down on all the other stuff in the container...

In a more serious sense, if you've got things configured right, the number of times you are execing into containers should tiny anyway. Instrumenting you code properly negates the need for a shell, particularly in prod.

[-]

plebbening@reddit

But bash is already using C and direct kernel calls. Might aswell write it in C then.

[-]

g_rich@reddit

At that point just write it in Assembly.

[-]

TheRealLazloFalconi@reddit

Real admins write machine code directly

[-]

ipsirc@reddit

You still need bash to run your script.

Why? Can you explain it?

[-]

aenae@reddit

The default shell in most linux distributions is bash-like. Sure, there are some exceptions, or it is a dressed down version (busybox for example).

So if you have a script, that does something scripty, you often start a terminal first to run that script. And that terminal runs bash.

[-]

ipsirc@reddit

So if you have a script, that does something scripty, you often start a terminal first to run that script.

...or you create a .desktop icon to launch it. Or a keycombo to start... or a systemd unit...

[-]

eman0821@reddit

The problem with Python Scripting is when modules, framework and language update changes across different versions. This can become inconsistent over the years requiring to write and update all the syntax of your scripts or else they wouldn't work correctly. Bash pretty much stays the same that's native to Linux/UNIX-Like. So if you are writing simple automation, Bash is more ideal. For writing more complex internal utility tools Python is great for that. Ansible is the defacto standard for large scale automation which uses Python behind the scenes.

[-]

aenae@reddit

Running a script is different from writing a script in my opinion. And while writing, you want to test it. Which usually means running it from the terminal to see error messages and be able to ctrl-c.

It is always a good idea for a linuxadmin to at least know the basics of bash scripting; ie simple loops, exit-codes, piping and redirecting output.

Sure, i could write a python script to run two commands, but only run the second command if the first one succeeds, or i could write 'command1 && command2' and be done.

[-]

ipsirc@reddit

Running a script is different from writing a script in my opinion. And while writing, you want to test it. Which usually means running it from the terminal to see error messages and be able to ctrl-c.

And how is this different from writing a program in C or Rust? Even there, in the early days of development, you will always start and test it via running it in a terminal. With this logic, you can write that he always needs bash for everything - but this does not mean that we are neither pro nor con about which language the OP should choose.

[-]

aenae@reddit

I'm not saying he should write everything in bash. I'm saying he should at least know some bash and bash scripting, regardless of in which language he writes his main scripts and programs.

[-]

ipsirc@reddit

Then refactor your sentence, please.

You still need bash to run your script.

[-]

stewie410@reddit

At my work, I've been hard limited to:

Linux:
bash, POSIX-sh for rare at -f occasions
groovy
Windows:
batch
powershell
vbscript, for one particular project (abandoned)
groovy

Given I'm both not a fan of Java, nor a Java dev, I will choose bash every time, unless Groovy makes a task significantly easier -- mostly because I'm most familiar with bash.

The right answer is to use whatever tool you're most comfortable with, that is most applicable to the task at hand.

[-]

serverhorror@reddit

PowerShell is well integrated with Windows. That's it.

[-]

GildedGashPart@reddit

Biggest “disadvantage” is usually just friction, not capability.

Batch is already there on every Windows box, same for PowerShell on modern Windows and Bash on pretty much every Linux machine. If you’re dropping a tiny script on random servers or coworkers’ machines, relying on Python or C# means you now care about runtimes, versions, paths, maybe venvs, dotnet SDK vs runtime, etc.

For quick glue stuff like renaming files, moving logs, tweaking environment vars, the shell tools are closer to the metal and usually integrate better with the OS. PowerShell especially is great at dealing with the registry, services, event logs and all that Windows-y stuff.

For anything non trivial though, Python / C# are way nicer to maintain, test and refactor. So it’s less “worse” and more “if this is a 10 line throwaway script that must run anywhere, use the shell. If it’s going to live longer than a day, Python or C# is probably the better call.”

[-]

kavaunix@reddit

The main advantage of bash etc. is that it's universally available, even on bare-bones installs, and that it has less overhead (the python runtime will eat a couple of megs and that a few hundred ms to start up).

In most cases this is negligible, so just use what you're comfortable with. Python is definitely more readable. Personally I use bash for very simple scripts, but python for anything bigger.

[-]

Stephonovich@reddit

sh is universally available. bash is not (nor zsh); and for that matter, there are major versioning differences: for example, MacOS stopped updating bash at v3.2, so you can’t use associative arrays if you’re targeting that.

This shouldn’t stop you from writing shell scripts in bash (or even zsh), but you do need to ensure that what you’re shipping doesn’t have an implicit requirement as an unhandled error.

[-]

Lammtarra95@reddit

The main reason is so you can hand over your shell script to the rest of the team who do not know c#, lisp, or any other fancy language. Otherwise you get six months of job security and 10 years being stuck maintaining your unicorn script. Although nowadays we can ask AI to explain, translate or improve it so maybe it is less important.

[-]

g_rich@reddit

Bash and Python when required.

Personally I’ve never used C# for scripting but I’m 100% Linux and Mac so I guess for those working on the Windows side C# / Powershell would be a thing.

[-]

Magneon@reddit

Syntax checking, type hints, and more robust support for things like testing are the main advantages of a scripting language vrs shell scripts.

Shell scripts are often a little quicker to write and test if you're familiar with the shell in question, but tend to become harder to maintain than say python if they are longer (at least for bash in my experience).

[-]

grumpysysadmin@reddit

If all you’re doing is running external commands with some minor logic, bash is fine. Once you start needing to do complex logic or handle complicated data structures, it’s worth moving to a more complex scripting language.

[-]

gmuslera@reddit

Size matters. If it is simple enough and heavily dependent on calling other programs, handling pipes and so on a bash command line or script may be smaller, more intuitive and easier to maintain. There are scripts that are born from one liners with added requirements.

[-]

rankinrez@reddit

Somewhat a matter of taste. I’d pick Python over them all.

Bash is good for very simple ones

[-]

michaelpaoli@reddit

Is shell, e.g. bash, not high enough level for you?

Perl and Python are also high level, while also allowing one to go quite low level too.

(Microsoft) Windows? This is r/linuxadmin, why would we want to compare to that Microsoft sh*t?

[-]

ipsirc@reddit

I use lua btw.

[-]

B0L1CH@reddit

Depends on what you want to do. Python is fine for most cases.
I like bash when doing a lot of stuff with files or awk when working with CSV files.