5 ms·

People do underestimate the shell. Particularly I see people shoehorning collections of commands into a Makefile, when a shell script would work just fine. On

People do underestimate the shell. Particularly I see people shoehorning collections of commands into a Makefile, when a shell script would work just fine. On the other hand, with a lot of glue work I do, I eventually want to something more complex (use lists and maps, complex string building and regexes, date handling) and while you /can/ do that in bash, I might as well start in Python and have everything in one language and take advantage of things like code sharing via modules. (And yes you can share code in shell, but again it’s not as nice.)

fragmede 5y ago
Might as well, yes, but I've found writing shell scripts in Python to be cumbersome because whatever flavor of os.system() I end up using just doesn't work well syntactically. I can run a command and pipe to a bunch more commands way easier in a shell because I'm already using a shell when interacting with the computer. Perl had this figured out, but proved unable to continue evolving (aka adding types, like Python/Ruby/JavaScript have managed to.) If there's a modern library/workflow that makes this not the case, I'm all ears!
- ilyash 5y ago
  > writing shell scripts in Python to be cumbersome because whatever flavor of os.system() I end up using just doesn't work well syntactically. This is exactly how I felt. Bash can't handle structured data well. Python (being general purpose programming language) can't handle calling external programs well because it's not the "focus" of the language. My shameless plug solution is a "real" programming language that can do both well (along with proper handling of exit codes and more goodies for "devops"y scripting). https://github.com/ngs-lang/ngs https://github.com/ngs-lang/ngs More about this feeling when you don't have a well fitting language for "devops"y scripting - https://ilya-sher.org/2017/10/10/why-i-have-no-favorite-programming-language/ https://ilya-sher.org/2017/10/10/why-i-have-no-favorite-prog...
  - laumars 5y ago
    There’s a few of these types of shells floating about these days. I personally use murex but Elvish seems popular too.
    - ilyash 5y ago
      NGS is programming-language-first while other modern shells are typically shell-first. Multiple dispatch would probably be the most prominent manifestation of this approach in NGS.
      - laumars 5y ago
        > NGS is programming-language-first while other modern shells are typically shell-first. Not always no. Even if your point were true, being programmer-first is not always a desirable feature. The vast majority of shell work is basic and repetitive. Most of the time people just want something that functions a little like Bash but less shitty for scripting. The fact that Powershell, LISP nor Python haven’t taken over the world for shell usage proves that a higher level language REPL generally makes for a shit daily shell. So usually you end up with just a small few purists using it. And that’s not really good enough. Whereas Oil, Elvish, Murex and even Fish (to a less dramatic extent) are looking at what makes a good shell and then fixing shell scripting within that shell. Having gone through the REPL phase myself with a great many different languages and found them all painful for daily use, I’m inclined to agree with shell-first approach. > Multiple dispatch would probably be the most prominent manifestation of this approach in NGS. Again, NGS isn’t unique in that regard. Murex has methods, Powershell has methods. I’ve not seen anything new in NGSs “Multiple Dispatch” nor “MultiMethod” docs that other alt shells aren’t also doing. Don’t take this the wrong way, it looks very impressive what you’re doing. But it’s not unique these days. And I say this having tried a great many options out there.
        ilyash 5y ago
        > being programmer-first is not always a desirable feature. programming-language-first allows convenient scripting. I could not think of a way to make anything shell-first be convenient for scripting (anything beyond tiny scale). > higher level language REPL generally makes for a shit daily shell. I think it proves that general purpose languages, where using them as a shell was afterthought "makes for a shit daily shell". NGS, on the other hand, has somewhat-bash-like (read: easily run external programs) syntax at the top level, which should be good for CLI. Want to use more advanced features that are typically associated with "real" programming languages? OK, pay the price, switch syntax with { ... } and have full blown programming language at your disposal, in the shell. > NGS isn’t unique in that regard. I do scan alternative shells from time to time. I could have missed but I didn't see multiple dispatch in any of them. Which ones have it? Just to clarify: In which shell you can define several methods with the same name and when called, the method to invoke is selected based on the types of the arguments? > Murex has methods, Powershell has methods. Just looked at Murex docs. No multiple dispatch mentioned. I did not even see how to define named parameters - https://murex.rocks/docs/commands/function.html https://murex.rocks/docs/commands/function.html There is a huge difference in having methods and multiple dispatch. > not unique these days NGS is a mixture of "borrowed" features and unique ones. Multiple dispatch is an old concept and has been implemented in other programming languages. Examples of things in NGS that I have not seen anywhere else: syntax for run-command-and-parse-output, proper handling of exit codes. Regarding exit codes. Typical approach to exit codes varies. Python - "I don't care, the programmer should handle it". Some Python libraries and other places - "Non-zero is an error". That's simplistic and does not reflect the reality in which some utilities return 1 for "false". bash (and probably other shells too) is unable to handle in a straightforward manner situation where external command can return exit codes for "true", "false" and "error". It just doesn't fit in the "if" with two branches. NGS does handle it with "if" with two branches + possible exception thrown for "error" exit code. Edit: and some other features around handling exit codes such as short syntax to provide expected exit code (any other exit code throws exception) Edit: clarification - NGS knows that some external programs have exit code 1 which does not signify an error.
nrclark 5y ago
I use Make extensively for glue scripts or build scripts that call other tools. Make gives you four big advantages over a pure shell-script: 1. Tab completion. All major bash-completion packages know how to show Makefile targets in response to a TAB. 2. Parallel, serial, or single-target execution. 3. Automatic dependency resolution between tasks. Tasks that build files can also use timestamps to see what needs rebuilding. 4. Discoverability. Anybody who sees a Makefile will usually understand that something is supposed to be run from the Makefile's directory. Chances are good that they'll check the tab-completions too. There are conventions for standard targets like 'clean' and 'all'. If you have a project with a build-process that has a bunch of small tasks that you might sometimes want to run piece-by-piece, Make is the perfect tool IMO.
- jandrese 5y ago
  Discoverability goes out the window the instant someone uses something like automake unfortunately. Then the makefile becomes an absolute mess of dummy targets and near gibberish.
  - fstrthnscnd 5y ago
    This would probably be the case for any language when the script is generated.
- totony 5y ago
  Since make does not sanitize input or handle error, I use it only for parallelism/dependency management and offload all build to shell scripts. I've found this to be way more maintainable.

fragmede 5y ago

Might as well, yes, but I've found writing shell scripts in Python to be cumbersome because whatever flavor of os.system() I end up using just doesn't work well syntactically. I can run a command and pipe to a bunch more commands way easier in a shell because I'm already using a shell when interacting with the computer. Perl had this figured out, but proved unable to continue evolving (aka adding types, like Python/Ruby/JavaScript have managed to.) If there's a modern library/workflow that makes this not the case, I'm all ears!

ilyash 5y ago
> writing shell scripts in Python to be cumbersome because whatever flavor of os.system() I end up using just doesn't work well syntactically. This is exactly how I felt. Bash can't handle structured data well. Python (being general purpose programming language) can't handle calling external programs well because it's not the "focus" of the language. My shameless plug solution is a "real" programming language that can do both well (along with proper handling of exit codes and more goodies for "devops"y scripting). https://github.com/ngs-lang/ngs https://github.com/ngs-lang/ngs More about this feeling when you don't have a well fitting language for "devops"y scripting - https://ilya-sher.org/2017/10/10/why-i-have-no-favorite-programming-language/ https://ilya-sher.org/2017/10/10/why-i-have-no-favorite-prog...
- laumars 5y ago
  There’s a few of these types of shells floating about these days. I personally use murex but Elvish seems popular too.
  - ilyash 5y ago
    NGS is programming-language-first while other modern shells are typically shell-first. Multiple dispatch would probably be the most prominent manifestation of this approach in NGS.
    - laumars 5y ago
      > NGS is programming-language-first while other modern shells are typically shell-first. Not always no. Even if your point were true, being programmer-first is not always a desirable feature. The vast majority of shell work is basic and repetitive. Most of the time people just want something that functions a little like Bash but less shitty for scripting. The fact that Powershell, LISP nor Python haven’t taken over the world for shell usage proves that a higher level language REPL generally makes for a shit daily shell. So usually you end up with just a small few purists using it. And that’s not really good enough. Whereas Oil, Elvish, Murex and even Fish (to a less dramatic extent) are looking at what makes a good shell and then fixing shell scripting within that shell. Having gone through the REPL phase myself with a great many different languages and found them all painful for daily use, I’m inclined to agree with shell-first approach. > Multiple dispatch would probably be the most prominent manifestation of this approach in NGS. Again, NGS isn’t unique in that regard. Murex has methods, Powershell has methods. I’ve not seen anything new in NGSs “Multiple Dispatch” nor “MultiMethod” docs that other alt shells aren’t also doing. Don’t take this the wrong way, it looks very impressive what you’re doing. But it’s not unique these days. And I say this having tried a great many options out there.
      - ilyash 5y ago
        > being programmer-first is not always a desirable feature. programming-language-first allows convenient scripting. I could not think of a way to make anything shell-first be convenient for scripting (anything beyond tiny scale). > higher level language REPL generally makes for a shit daily shell. I think it proves that general purpose languages, where using them as a shell was afterthought "makes for a shit daily shell". NGS, on the other hand, has somewhat-bash-like (read: easily run external programs) syntax at the top level, which should be good for CLI. Want to use more advanced features that are typically associated with "real" programming languages? OK, pay the price, switch syntax with { ... } and have full blown programming language at your disposal, in the shell. > NGS isn’t unique in that regard. I do scan alternative shells from time to time. I could have missed but I didn't see multiple dispatch in any of them. Which ones have it? Just to clarify: In which shell you can define several methods with the same name and when called, the method to invoke is selected based on the types of the arguments? > Murex has methods, Powershell has methods. Just looked at Murex docs. No multiple dispatch mentioned. I did not even see how to define named parameters - https://murex.rocks/docs/commands/function.html https://murex.rocks/docs/commands/function.html There is a huge difference in having methods and multiple dispatch. > not unique these days NGS is a mixture of "borrowed" features and unique ones. Multiple dispatch is an old concept and has been implemented in other programming languages. Examples of things in NGS that I have not seen anywhere else: syntax for run-command-and-parse-output, proper handling of exit codes. Regarding exit codes. Typical approach to exit codes varies. Python - "I don't care, the programmer should handle it". Some Python libraries and other places - "Non-zero is an error". That's simplistic and does not reflect the reality in which some utilities return 1 for "false". bash (and probably other shells too) is unable to handle in a straightforward manner situation where external command can return exit codes for "true", "false" and "error". It just doesn't fit in the "if" with two branches. NGS does handle it with "if" with two branches + possible exception thrown for "error" exit code. Edit: and some other features around handling exit codes such as short syntax to provide expected exit code (any other exit code throws exception) Edit: clarification - NGS knows that some external programs have exit code 1 which does not signify an error.

nrclark 5y ago

I use Make extensively for glue scripts or build scripts that call other tools. Make gives you four big advantages over a pure shell-script: 1. Tab completion. All major bash-completion packages know how to show Makefile targets in response to a TAB. 2. Parallel, serial, or single-target execution. 3. Automatic dependency resolution between tasks. Tasks that build files can also use timestamps to see what needs rebuilding. 4. Discoverability. Anybody who sees a Makefile will usually understand that something is supposed to be run from the Makefile's directory. Chances are good that they'll check the tab-completions too. There are conventions for standard targets like 'clean' and 'all'. If you have a project with a build-process that has a bunch of small tasks that you might sometimes want to run piece-by-piece, Make is the perfect tool IMO.

jandrese 5y ago
Discoverability goes out the window the instant someone uses something like automake unfortunately. Then the makefile becomes an absolute mess of dummy targets and near gibberish.
- fstrthnscnd 5y ago
  This would probably be the case for any language when the script is generated.
totony 5y ago
Since make does not sanitize input or handle error, I use it only for parallelism/dependency management and offload all build to shell scripts. I've found this to be way more maintainable.