[geowwy]

  > A lot developers just choose shell(sh, bash, ...) scripts for such tasks,
  > by using < to redirect input, > to redirect output and '|' to pipe outputs.
  > In my experience, this is the only good parts of shell script.

If you try to use shell as a general purpose programming language, of course it sucks.

If you treat shell as a DSL for files and streams, nothing can beat it. Shell is amazing.

I'm sceptical a bunch of Rust macros can beat shell. I think you'd better off writing a few smaller programs that use STDIO and stringing them together with shell.

[dathinab]

Actually it succs bad time at file and stream processing (which I have done a bunch of with bash in recent years).

It's only if you want to do trivially simple file and stream processing with a prototype level of robustness.

It's too prone to all kind of unexpected bugs wrt.:

- unusual file names

- unusual stream output

- error handling both for expected and unexpected errors (set -euo pipefail can help a bit)

- accidental cross talking/pollution through env variables (local+declare+arrays do slightly improve this)

- accidental output/stream pollution through debug messages,warning or unexpected formatting interfaces

- hard to process, brittle plain text data

Also:

- doing the steam proceeding, traditional tools like cut,tr,sed,grep,etc. often have bad to terrible UX and also often have quirks which can cause bugs for edge cases (they what ok for the 90th, but we no longer have 80char line length limits and learned a lot about cli UX since then)

I used small bash scripts all the time but the more I do the more I realize that it's technologically left behind and no longer appropriate for the current times.

I frequently do consider replacing bash as my system shell with e.g. python+some library or something similar and the shell is for me still the main way to interact with my PC, I don't even have a GUI file manager!

Through I need something reasonable responsive so not a compiled language.

I'm also not a fan with implicit cached binaries lying around somewhere, maybe leaking disk space.

Through my prompt is actually computed by a small rust program.

Edit: writing from a phone, swipe like keyboards make it feasible but man I which they wouldn't mix up words that often.

Edit: the reason I'm still using sh/bash/fish/zsh and similar is because when I consider switching I get overnighted in what I like to have, realize that it's to much work for me now and therefore postpone it to later.

[masklinn]

> If you try to use shell as a general purpose programming language, of course it sucks.

> If you treat shell as a DSL for files and streams, nothing can beat it. Shell is amazing.

The problem is that any non-trivial shell script is a mix of the two, so you find yourself torn apart by the inconvenience of "file and streams" in most languages (though really it's mostly subprocesses), and the inconvenience of literally everything else in shells.

[amalcon]

This is the one space where I actually like Perl: for shell scripts that grew up a bit, but still amount to mostly manipulating text files and streams.

[dijit]

I often find myself composing smaller programs which I then call/pipe/chain with bash, this looks pretty messy because I’m a sysadmin, not a programmer.

But I do think it works better than trying to do everything in one place.

[usrusr]

> If you treat shell as a DSL for files and streams, nothing can beat it.

My cursory glance at this lib (and what I picked up from other comments) suggests that it's based on exactly this thought:

Take the tiny subset of shell syntax that makes it awesome and reimplement it as an internal DSL in a host language that has sane control flow etc.

[jabirali]

> If you treat shell as a DSL for files and streams, nothing can beat it. Shell is amazing.

On the other hand, wouldn’t you just define anything that beats it also a shell? In my opinion, Fish beats Bash and Zsh in this area, and I would definitely call it a shell even though it’s not a POSIX-compatible shell. A more extreme example would be PowerShell (I’m not a fan but some people love it).

Where would you draw the line between a “shell” and an “interpreted scripting language that beats POSIX shells on dealing with files and streams”?

[barrkel]

Does fish handle <(outputting command) yet?

Powershell isn't even concurrent, its usefulness is along a different dimension to job coordination and control.

[jabirali]

Do you mean that you want `cmd2 <(cmd1)` as a synonym for `cmd1 | cmd2`? In that case, I’m happy it doesn’t; it drastically lowers readability compared to left-to-right command pipelines, and I don’t see what value it adds.

[viraptor]

Not quite. "<(cmd1)" creates a pipe, connects cmd1 output to it and replaces the expression the pipe name. With one argument you can often use "cmd1 | cmd2 /dev/stdin", but with two you need something better.

Think "diff <(something) <(other)" without using temporary files.

[rustshellscript]

Yes, I also use this for automatically capturing command error messages with timestamps into logs: https://github.com/rust-shell-script/bash_cmd_lib/blob/0b0a6...

However this can be fragile in bash script since any sub shell command can fail. I am still wandering how to support it in this rust_cmd_lib library.

[viraptor]

> Powershell isn't even concurrent

It's got "Start-Job" and now gets "ForEach-Object -Parallel". What else do you think it's lacking?

[rattray]

> If you treat shell as a DSL for files and streams, nothing can beat it.

That sounds exactly like the approach of this crate - easily let you use "the files and streams DSL" directly from a general purpose programming language (Rust). You get full access to shell, but only need to use it where it's useful.

I've done the same thing many times with Python, Node, and Ruby, just with template strings which isn't as pretty as this rust macro (even if the latter can be a bit mysterious)