41–50 of 83 posts
Earlier quoted context omitted.
Does fish handle Powershell isn't even concurrent, its usefulness is along a different dimension to job coordination and control.
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.
I am not a huge fan of copying the shell language wholesale and wrapping inside a macro. Since macros can execute arbitrary code, this makes me feel uneasy that the strings are just executed within a shell context, with all the appropriate, bug-prone, expansion done by the shell. Seeing "ls /nofile || true;" makes me worry that "||" is actually passed to the shell wholesale. There's also no transparency about how the…
This plumbum has its own “cp”, “cat” .., which is similar to shelljs and it looks like a lot of people like this idea which can also be supported by this library in the future.
> A lot developers just choose shell(sh, bash, ...) scripts for such tasks, > by using 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 s…
> 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…
Earlier quoted context omitted.
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.
Not quite. " Think "diff <(something) <(other)" without using temporary files.
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.
This is great! What about "set -euxo pipefail"? I see you were using eprintln before the commands, could we have a "set" macro that would do that for us?
This reminds me of the python version of this called xonsh https://xon.sh/ I really like the idea, but it was missing some simple features that bash had. I can't recall them right now but after an hour of trying to convert a simple bash script, I gave up. That was a year ago. Maybe things changed. I'll give this and xonsh a go again because I just really dislike bash. Thanks for the project!
> A lot developers just choose shell(sh, bash, ...) scripts for such tasks, > by using 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 s…
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.
https://github.com/oconnor663/duct.rs
I wanted to solve the same problem, originally in Python (https://github.com/oconnor663/duct.py). It's surprisingly annoying to do pipelines and redirections, compared to how easy they are to do in the shell. Lots of libraries try to address this, but most of them seem do it by emulating shell syntax within the host language, using operator overloading or other magic like that. I think that's a limiting choice. (For example, can you use `cd` to change the working dir for the left half of a pipeline but not the right half? In Bash you would use a "subshell" for this.) Instead, I think it's sufficient to build an API out of regular objects with regular methods. The result doesn't look like shell code, but it's easier to reason about, and more consistent across different languages.
Earlier quoted context omitted.
Since macros can execute arbitrary code, this makes me feel uneasy that the strings are just executed within a shell context, with all the appropriate, bug-prone, expansion done by the shell. Its a shame you didn't bother to look at the source code before criticizing. Someone put a lot of work into this library and its actually pretty cool. The package parses the code in the macros [1] and then calls 'std:Process::Co…
I don't think the parent said this is not parsed well, or at least I didn't read it that way. I share the feeling that you see that code and unless you know the implementation it's not clear what shell brokenness is carried over and what isn't. And which shell and version is being emulated. It's much easier to set expectations with a new syntax that's also easier to document than "what to expect of this macro".