Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Using Rust to write shell-script like tasks

github.com

Post reply on HN
Print view View original

31–40 of 83 posts

Re: Show HN: Using Rust to write shell-script like tasks

#31

Post by barrkel »

jabirali wrote: post #24
geowwy wrote: post #11

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

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

Re: Show HN: Using Rust to write shell-script like tasks

#32

Post by dijit »

masklinn wrote: post #18
geowwy wrote: post #11

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

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.

Re: Show HN: Using Rust to write shell-script like tasks

#33

Post by cheez »

rhn_mk1 wrote: post #5

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…

Oh this plumbum is nice.

Re: Show HN: Using Rust to write shell-script like tasks

#34

Post by usrusr »

geowwy wrote: post #11

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

Re: Show HN: Using Rust to write shell-script like tasks

#35

Post by feanaro »

intc wrote: post #17
kazinator wrote: post #6

Earlier quoted context omitted.

> unsafe Rust ... since you’re now forking external code Are you saying that Rust becomes unsafe because it used a C program as a subroutine? E.g. "tar xvf -" or whatever? What is the fix: rewrite tar, awk, scp and whatever else as Rust functions? That's a lot of work. I'm surprised that you're simultaneously overlooking what ought to be a more gaping problem: that every system call made by a Rust program is a trip t…

Could you please be more specific how it's a "gaping problem" that the underlying kernel is written in C? I think even you'd write a pure Rust kernel from scratch it would take a considerable time to achieve the same quality/performance ratio as we are currently witnessing with C based kernels (*BDS & Linux). It's so easy to throw these "radical claims". Yes? =)

I think the idea is that if calling external C binaries is a problem, then a kernel written in C is an even larger problem. It was meant as reductio ad absurdum.

Re: Show HN: Using Rust to write shell-script like tasks

#36

Post by laumars »

darthrupert wrote: post #23

If this is a fun proof of concept, it's nice. If somebody uses this in an actual system, it's terrifying. edit oh, Rust is now a thing where even the bad ideas need to be praised without caveats. Gotcha

It’s pretty crazy isn’t it. Things like this are fun as pet projects but the stuff of nightmares in real codebase that need supporting for years and by a department that will have the usual churn of staff.

I’ve managed enough teams and enough code bases in my time to know that sometimes the smartest code is the least clever. If someone if finding the need to write a shell script in Rust then I’d suggest they need to re-evaluate the problem they’re trying to solve.

Re: Show HN: Using Rust to write shell-script like tasks

#37

Post by laumars »

joshuamorton wrote: post #25
laumars wrote: post #20

Earlier quoted context omitted.

> So while yes, calling "rm -rf /" is dangerous, it is no more dangerous when done in rust than anywhere else, since you're just calling a subprocess, and the subprocess API is a safe API. There's nothing "unsafe" (in the rust sense, meaning type- or memory-unsafe) about doing so. The point is that code doesn't belong in Rust to begin with! > Yes, but if you have to shell out at some point, the difference between cal…

> The point is that code doesn't belong in Rust to begin with! I'll reiterate: it is often safer to embed short snippets of bash into other languages than to invert control and call out to other languages from bash. By calling out to bash, you do the majority of your work in better languages. > No it isn't. Code auditing and vetting has been a thing for years. Say you have a CI pipeline that hooked into Shellcheck to…

> I'll reiterate: it is often safer to embed short snippets of bash into other languages than to invert control and call out to other languages from bash. By calling out to bash, you do the majority of your work in better languages.

"It depends" is a better way of putting it. However the advantages of embedding Bash doesn't, in my opinion, make up for the problems it creates by obfuscating those calls. Putting Bash inside separate .sh files clearly draws attention to those calls.

It's the same reason Rust has the unsafe block - to draw developer attention to unsafe code. So what I'm talking about here is more idiomatic to Rust.

Not to mention this also creates potential surprises due to being a custom parser which could trip new developers on that code base. Smarter code creates fewer surprises, even if that sometimes means uglier code.

In short, if inlining a shell script in Rust seems like a good idea, then I'd suggest one would need to reinvestigate the original problem and possible solutions. There's bound to be a more predictable and maintainable solution out there, even if it is a little less interesting / fun / trendy.

> You're making a rather particular set of assumptions there.

Inlining code is often regarded as an anti-pattern. Separate out your concerns, separate out your languages. It helps with your IDE (eg syntax highlighting, code completion, etc), your code validation tools (eg Shellcheck), with humans understanding the code (path of least surprises), etc.

> The three you originally mentioned...

They weren't the original points I mentioned nor even the only points I've discussed since. They were only a breakdown of one of the points I had raised.

Re: Show HN: Using Rust to write shell-script like tasks

#38

Post by viraptor »

papaf wrote: post #26
rhn_mk1 wrote: post #5

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…

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

Re: Show HN: Using Rust to write shell-script like tasks

#39

Post by jabirali »

barrkel wrote: post #31
jabirali wrote: post #24

Earlier quoted context omitted.

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

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.

Re: Show HN: Using Rust to write shell-script like tasks

#40

Post by viraptor »

barrkel wrote: post #31
jabirali wrote: post #24

Earlier quoted context omitted.

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

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

> Powershell isn't even concurrent

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

Post reply on HN