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

11–20 of 83 posts

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

#11

Post by geowwy » 

  > 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 shell. I think you'd better off writing a few smaller programs that use STDIO and stringing them together with shell.

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

#12

Post by scns »

yisonPylkita wrote: post #3

My god, this super useful when you have a mix o shell commands and processing text output from them. Bash isn’t particularly easy to work with parsing non-trivial strings in a readable way (I’m looking at you awk)

Where are nontrivial strings easy to parse?

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

#14

Post by laumars »

joshuamorton wrote: post #9
laumars wrote: post #8

Earlier quoted context omitted.

There’s a few problems with forking out: 1. Do those programs exist and what happened if they don’t? That behaviour is already understood in Bash, less so in random 3rd party Rust libraries. 2. Is ‘tar’ calling ./tar, /bin/tar or some other instance of tar? And how do you find out? (eg easy to check $PATH in Bash but does this library honour that? Easy to ‘which tar’ but is that going to be the same tar that this lib…

None of these are, as far as I can tell, "unsafe" in the rust sense. They won't result in memory safety issues in the current process. Your concern is a generic concern about shelling out which maybe makes sense in some cases, but is untenable in general. I also don't see how 1 & 2 are real problems. From looking at the readme I understand what happens if tar doesnt exist. The macro raises an error. This is similar t…

It’s inside a .rs file so I don’t see how it’s not unsafe in the Rust sense. Maybe when I drew parallels with the “unsafe” block wasn’t fair but safety isn’t just about memory safety. Any seasoned developer will tell you that writing safe software is a multi-paradigm problem.

The MVC point is that by having shell scripts separated out as their own .sh file means they draw attention to themselves when auditing code. Inlining shell scripts do not.

Writing your own shell script parser also introduces other surprises to new developers to your code base (eg what POSIX tokens are supported?).

I’ve seen all to often people trying to get clever because they don’t like a particular ugly but well understood standard and it usually results in more problems than it solves. Which is fine if it’s a personal pet project but such solutions don’t belong in production code.

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

#15

Post by ilovetux »

yisonPylkita wrote: post #3

My god, this super useful when you have a mix o shell commands and processing text output from them. Bash isn’t particularly easy to work with parsing non-trivial strings in a readable way (I’m looking at you awk)

I apologize, but I must disagree. Awk is literally amazing once you get used to writing actual scripts instead of trying for the ever-elusive and often-untenable one-liners.

Noone is using `python -c` syntax for constructing one-liners and i think thats helping adoption of python. I have no idea why one-liners are seen as desirable when they're often hard to read and debug.

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

#16

Post by joshuamorton »

laumars wrote: post #14
joshuamorton wrote: post #9

Earlier quoted context omitted.

None of these are, as far as I can tell, "unsafe" in the rust sense. They won't result in memory safety issues in the current process. Your concern is a generic concern about shelling out which maybe makes sense in some cases, but is untenable in general. I also don't see how 1 & 2 are real problems. From looking at the readme I understand what happens if tar doesnt exist. The macro raises an error. This is similar t…

It’s inside a .rs file so I don’t see how it’s not unsafe in the Rust sense. Maybe when I drew parallels with the “unsafe” block wasn’t fair but safety isn’t just about memory safety. Any seasoned developer will tell you that writing safe software is a multi-paradigm problem. The MVC point is that by having shell scripts separated out as their own .sh file means they draw attention to themselves when auditing code. I…

> It’s inside a .rs file so I don’t see how it’s not unsafe in the Rust sense. Maybe when I drew parallels with the “unsafe” block wasn’t fair but safety isn’t just about memory safety. Any seasoned developer will tell you that writing safe software is a multi-paradigm problem.

If I call a function that can result in an error condition, and I correctly handle the error condition, my code is not "unsafe".

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 MVC point is that by having shell scripts separated out as their own .sh file means they draw attention to themselves when auditing code. Inlining shell scripts do not.

Yes, but if you have to shell out at some point, the difference between calling to myscript.sh that contains "foo --flag x" and directly shelling out to "foo --flag x" is practically nonexistant. And yes, there are cases when you need to shell out to another program, because otherwise you reduce yourself to needing to do everything in bash, or have bash be the entrypoint in some weird inversion of control scheme, and I'd much prefer to construct a single command invocation in bash than to parse a complex set of flags, for example.

Is this better than just using rust's builtin `std::process::Child`? Maybe not, but all of your concerns apply equally to using that.

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

#17

Post by intc »

kazinator wrote: post #6
laumars wrote: post #4

Please people, don’t do stuff like this for anything other than personal projects. You might think it’s safer than writing Bash but it isn’t. It results in unsafe Rust code since you’re now forking external code that might be missed by people who are strictly vetting for code inside “unsafe” blocks. Ironically anyone who writes she’ll scripts will know that there are problems with shell scripting but thankfully dot-s…

> 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? =)

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

#18

Post by masklinn »

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 everything else in shells.

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

#19

Post by enhray »

scns wrote: post #12
yisonPylkita wrote: post #3

My god, this super useful when you have a mix o shell commands and processing text output from them. Bash isn’t particularly easy to work with parsing non-trivial strings in a readable way (I’m looking at you awk)

Where are nontrivial strings easy to parse?

Ruby? Of all of the scripting languages out there, I find most suitable to write small scripts to transform complex text to something more suitable.

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

#20

Post by laumars »

joshuamorton wrote: post #16
laumars wrote: post #14

Earlier quoted context omitted.

It’s inside a .rs file so I don’t see how it’s not unsafe in the Rust sense. Maybe when I drew parallels with the “unsafe” block wasn’t fair but safety isn’t just about memory safety. Any seasoned developer will tell you that writing safe software is a multi-paradigm problem. The MVC point is that by having shell scripts separated out as their own .sh file means they draw attention to themselves when auditing code. I…

> It’s inside a .rs file so I don’t see how it’s not unsafe in the Rust sense. Maybe when I drew parallels with the “unsafe” block wasn’t fair but safety isn’t just about memory safety. Any seasoned developer will tell you that writing safe software is a multi-paradigm problem. If I call a function that can result in an error condition, and I correctly handle the error condition, my code is not "unsafe". So while yes…

> 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 calling to myscript.sh that contains "foo --flag x" and directly shelling out to "foo --flag x" is practically nonexistant.

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 validate your .sh files for errors, that same pipeline wouldn't vet any pseudo shell code inlined in Rust.

> Is this better than just using rust's builtin `std::process::Child`? Maybe not, but all of your concerns apply equally to using that.

Not all, only the concerns you've cherrypicked.

Post reply on HN