Oh, nice. I’ll check it out.

Good question.

I choose PowerShell over Python when I need to call out to an existing command line utility, because I find the Python subprocess module is a huge pain in the ass.

PowerShell has about 80% of the power and readability of Python, while actually being a native shell.

Yes, and Rust with incremental compilation is pretty fast to iterate as well, as long as you don’t use massive libraries/build-scripts etc.

Not op, but I feel the same as them.

Compared to C++, Rust has a very good toolchain and libraries. With C++ setting up a project that has dependencies is… painful. I’m a full-time C++ programmer with over 8 years of experience and if I didn’t have to, I would never choose it for something new.

With Rust creating a new project and adding dependencies is trivial. There are a lot of great libraries and the ease with which you can use them is very empowering.
Clap and serde are super powers for CLI programs 😀

For smaller scripts that don’t yet “deserve” full rust treatment, I now use nushell for personal projects.

I personally don’t have any real experience with Go. Lots of smart folks I work with love it. In general, most of what I have read suggests that Rust is better suited to CLI tooling. For my use case it came down to:

• Rust’s cargo system
• The clap crate (which supports building out bash shell completion scrips via a Rust build script). Basically means I can generate a completion script at compile time and include this in the package I distribute to users)
• Rust’s out of the box performance
• The heavy lifting done by the borrow checker in bringing safety

Not him, but I much more like the type-system of rust (e.g. enums).

I personally don’t have any real experience with Go. Lots of smart folks I work with love it. In general, most of what I have read suggests that Rust is better suited to CLI tooling. For my use case it came down to:

• Rust’s cargo system
• The clap crate (which supports building out bash shell completion scrips via a Rust build script. Basically means I can generate a completion script at compile time and include this in the package I distribute to users)
• Rust’s out of the box performance
• The heavy lifting done by the borrow checker in bringing safety

What do you like about fish? Have you tried zsh? I’m in the market for a new shell too.

Modern Perl

Perl or Raku?

Oh, I didn’t mean to say, you should throw out your shell scripts. For anything less than, say, 20 lines, they’re perfectly appropriate.

I’m saying, Rust et al start to feel like a good choice from, say, 100 lines upwards, and I just don’t think, it’s worth bridging the gap between those two.

In particular, you can build a function that allows you to run commands without much boilerplate, e.g.: run("echo hello | tee out.txt");
(The implementation just appends that argument to Command::new("sh").arg("-c") and runs it.)

That way, you can do the more complex things in Rust, whether that’s control flow or something like modifying a JSON file, without giving up the utility of all the CLI tools on your system…

As I already responded to others, my comment was meant in the context of the question, so I would not learn a scripting language in addition to Bash + a programming language.

For just running commands one-after-another, Bash is basically a minimal encoding, so no reason not to use it.

When you do start to need if-elses, loops etc., that’s where Bash starts to become somewhat difficult to read. And personally, as someone who’s not fluent in Bash control flow, I found it quite useful to do the control flow in my programming language of choice, but still just calling commands like you’d do in Bash.

Of course, this is a non-standard setup, and most target hosts will have Bash pre-installed, not rust-script, so it does obviously make a lot of sense to continue using Bash for what you’re doing.
In general, my comment was meant for programmers. An ops person might know a full-fledged programming language, but still want to learn Python, because they need to write tons of Ansible tasks or whatever.

You could look at logrotate if you don’t want to do something custom

The expression syntax for the GNU find command is very powerful. I would expect that it is up to the task. If you don’t have the GNU find command with it’s extensions I could see how it’s would be difficult.

As @damium@programming.dev says you may be able to do this with find command. This command lists all PDF files under ~/tmp that were created more than 7 days ago and does a directory listing. You could use this as a basis to move create an archive of individual files.

find ~/tmp -ctime +7 -iname "*pdf" -exec ls -rlht {} \;

The find command also has a -delete flag.

I have in the past used this combination to implement file management. I don’t have access to the script any more. I don’t remember why we used a shell script rather than logrotate as per @oddityoverseer@lemmy.world