5 ms·

> Traditionally, UNIX commands were written under the assumption they were going to be used primarily by other programs. They had more in common with functions

> Traditionally, UNIX commands were written under the assumption they were going to be used primarily by other programs. They had more in common with functions in a programming language than with graphical applications. Not quite. They were primarily intended for interactive use within a login shell. There are the programs which generate output on stdout (ls, cat, find, tty, who, date), and there are the "silent" text filters (tr, grep, cut, uniq, sort, wc). A one-liner would enable you to do basic computing tasks in that era. Any complex program would be written in C. After the appearance of DSLs like sed and AWK, certain string-heavy programs were offloaded to the shell. The shell is not a sane programming environment and was never intended as such.

rollcat 3y ago
> The shell is not a sane programming environment and was never intended as such. There are 10kloc C programs that could be 10 lines of shell and there are 1kloc shell programs that could've been 100 lines of C. Both kinds are nowadays probably better done in Python or Lua, but the shell and C are what's most universally available.
- bluetomcat 3y ago
  > 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.
  - 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.
samatman 3y ago
Sane or not, shells are programming languages, and in early Unix this was quite a bit more prominent and obvious, the fanout into sh, bash, ksh, and csh being exemplary. To me it makes total sense to think of the standard POSIX toolkit as the standard library of the various shell languages, that seems basically correct in fact.

rollcat 3y ago

> The shell is not a sane programming environment and was never intended as such. There are 10kloc C programs that could be 10 lines of shell and there are 1kloc shell programs that could've been 100 lines of C. Both kinds are nowadays probably better done in Python or Lua, but the shell and C are what's most universally available.

bluetomcat 3y ago
> 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.
- 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.

samatman 3y ago

Sane or not, shells are programming languages, and in early Unix this was quite a bit more prominent and obvious, the fanout into sh, bash, ksh, and csh being exemplary. To me it makes total sense to think of the standard POSIX toolkit as the standard library of the various shell languages, that seems basically correct in fact.