Hacker News Reader

Comment by bluetomcat | Hacker News Reader

> There are 10kloc C programs that could be 10 lines of shell

Only when the shell calls other external C programs. Ten lines of calling ffmpeg or curl is not shell programming.

> there are 1kloc shell programs that could've been 100 lines of C

The 1kloc shell programs are fragile spaghetti that breaks in weird ways. Any invocation of an external program can fail for a variety of reasons, and the shell doesn't provide adequate mechanisms for dealing with it, apart from exit codes and filtering error text output.

View on HN

> Only when the shell calls other external C programs. Ten lines of calling ffmpeg or curl is not shell programming.

100% wrong. this is what the shell was designed to do and where it is at it's best.

often shell "scripts" are used like "macros" or power-tools, shortcuts to save off a complex invocation or workflow. error handling isn't as important in a one-off and "adequate" is whatever gets the job done for the user, which it does.

it's rare that 1kloc shell script is the best engineering choice vs. (in the ancient days) Perl or (today) Python. e.g. "real" programming languages. you mostly should not write large programs in shell. and you really should not glue together pipelines of external programs using, for example, Python or C, which is onerous.

ah, the HN crowd: where everything is either black or white, great or terrible. how about "each to his own" and "use the right tool for the job"

It's not rare at all. In every corporate environment I've worked in, my choices were PowerShell or 3 months of red tape, meetings, and security audits.

I get that in a dev shop that's not the case, but most businesses employ 0 devs. So people end up being forced into shell scripting because it's the only approved option.

At least PowerShell gives you access to the entirety of .NET, even if syntax is not ideal for non-interactive use in many cases.

Yup. My "scripts" end up with a lot of .NET stuff in there. I'd rather use Python, but being forced to use PS for years, I've come to like it.

Depending on what you're doing, C# might also be an option - since the compiler is a part of the .NET Runtime (not just SDK), it's available on any Windows install with PowerShell these days. It's too bad that the system one is always an old version that doesn't do .csx, but still.

it's not rare, it's rare that it's the best engineering choice.

if your management can't allow even a python script, but it can allow bash? then it's not an engineering problem. as you even allude - your business does not have a software engineering culture.

a good engineering culture does not depend on job titles or budget or degree either. but it can't exist without healthy management.

It's much easier to control allowed functionality in PowerShell via security policies. Python is comparatively a free for all. It makes sense in a non-dev environment.

> Ten lines of calling ffmpeg or curl is not shell programming

Ten lines of calling ffmpeg or curl is shell programming in precisely the same sense that 100 lines of C that `#include <sys/socket.h>` are C programming.

If your code isn't standing on the shoulders of giants, you're probably wasting everyone's time.

> Any invocation of an external program can fail for a variety of reasons, and the shell doesn't provide adequate mechanisms for dealing with it, apart from exit codes and filtering error text output.

True, handling multiple sub-processes is difficult in most Unix shells. This is a function where Powershell could have done so much better, but didn't. It is somewhat better than bash&co, but could have been much more so. Python does it much better than Powershell does.

Reply on news.ycombinator.com