3 ms·

> 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 s

> 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.

shadowgovt 3y ago
> 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.
fargle 3y ago
> 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"
- bongodongobob 3y ago
  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.
  - int_19h 3y ago
    At least PowerShell gives you access to the entirety of .NET, even if syntax is not ideal for non-interactive use in many cases.
    - bongodongobob 3y ago
      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.
      - int_19h 3y ago
        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.
  - fargle 3y ago
    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.
    - bongodongobob 3y ago
      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.
numeromancer 3y ago
> 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.

shadowgovt 3y ago

> 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.

fargle 3y ago

> 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"

bongodongobob 3y ago
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.
- int_19h 3y ago
  At least PowerShell gives you access to the entirety of .NET, even if syntax is not ideal for non-interactive use in many cases.
  - bongodongobob 3y ago
    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.
    - int_19h 3y ago
      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.
- fargle 3y ago
  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.
  - bongodongobob 3y ago
    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.

numeromancer 3y ago

> 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.