I’m curious on why you would recommend Lua if available. Is language speed a typical limiting factor for your scripts?
I’m mostly asking since when I was forced to use the language it was nothing but annoyance. The 1 indexing and “if then/for do” will annoy me till my grave.
just for simple tasks, where i need something between the simplicity of bash and the type safety of rust. its just my personal preference when it comes to scripting, although i do believe it should be the first consideration for choosing a user friendly but powerful embedded or config language, like for neovim, especially if performance is a concern, but it will ofc not always be the best option. the 1 index is certainly annoying though, but i would personally rather that than anything to do with python, especially whitespace. the if...then and for...do is the same as bash, so i dont think its that bad
My criteria for another scripting language included that it should be preinstalled on all target systems (i. e. Debian and Fedora), it should be an interpreted language and it needs to have type safety.
Afterall I settled with Python due to its popularity, its syntax and features (type safety since v3.6, etc.) and the fact that it is preinstalled on many Linux distributions. System components often use Python as well, which means that libraries to interact with the system tend to be included by default.
I would say it’s Python, so I use ChatGPT to code it for me if bash is not enough. If something that I can call “project” instead of “script” - I just use Go for it.
Personally, I don’t feel like it’s worth learning a separate scripting language when you’re comfortable with a full-fledged programming language.
Python, Lua etc. used to be on a whole different level of usability, when compared to C. But compared to modern, high-level languages, the difference is marginal. Not to mention that at least compared to Rust, they start to look rather antique, too, and lack in robust tooling.
If you don’t feel like maintaining a whole git repo, use e.g. rust-script.
Yeah as weird as it sounds to use a “low”-level systems programming language such as Rust. Rust works surprisingly well as “script” language. (And you don’t have to deal with the ugliness of bash, admittedly though, that bash is quite a bit more concise when using a lot of program executions and piping the results etc.)
A shell script can be more concise if you’re doing a lot of shell things. Keeps you from having os.system() all over the place.
Things like “diff the output of two programs” are just more complex in other languages.
I love rust, but replacing my shell scripts with rust is not something I would consider doing any more than I’d consider replacing rust with my shell scripts.
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…
Somewhat of a weird addendum, but I actually only realized, you could port directly over like that, while writing the above comment.
Now I actually tried it on a 22 lines long shell script that I’ve been struggling with, and holy crap, I love it.
Like, I should say that I have always been (and likely will always be) shit at shell scripting. Any time I wanted to do a basic if, I had to look up how that works.
As a result, even those 22 lines were ripe with code duplication and I always felt really unsure about what will actually happen during execution.
Well, rightfully so. While porting over, I realized I had a bug in there, which has been annoying me for a while, but I always thought, well, it is a shitty shell script. I still remember thinking, I should probably not implement it like that, but then leaving it anyways, because I felt it would become unreadable with the shell syntax.
Now it actually feels maintainable, like I can even easily expand on it.
And I have to say that rust-script is really smooth. I barely notice that it’s compiling during the first run after changing the script file, and it’s fully cached afterwards, so it executes instantly.
I’ll still have to check for libraries that basically provide such a run() function/macro for me, but yeah, basically my threshold for not using shell scripts just dropped to any kind of control flow being involved.
Yeah the strict type-system of Rust is great at finding issues.
I think when understanding, that bash is basically only programs with parameters ([ is a program that takes all kinds of parameters and as last parameter ]) then bash is quite ok for stuff that doesn’t need a lot of algorithms, i.e. passing the in and out from one program to another. But as soon as there’s basic logic, You’ll want to use a fully-fledged programming language.
Also the maintainability aspect: You can just start using fancy stuff you never want to use in bash and it can slowly grow into a library or application or something like that.
Btw. I have started a syntax-sugar library/crate that creates typing information for all kinds of programs via the builder-type-state-pattern, so that you don’t always have to look up man etc. and that it should be more convenient to execute programs (not open sourced yet, and low priority for me as I’m working on various other exciting projects currently)
I make bash scripts to automate the configuration of new servers. Stuff like install packages, create users, create groups, configure the database, manage permissions…
I feel like that sort of stuff would be a nightmare to do in high level languages but maybe I’m just too used to bash.
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 can create quick and dirty CLIs, invoke shell commands, and have all of python available for things like parsing config files, getting and setting environment variables, and making remote REST calls.
But I 'd like to recommend starting with subprocess module which is built-in. Then go ahead and see what the extensions have to offer… There are other that may come handy, like Typer from Tiangolo, and Fire from Google.
What are you trying to achieve in Bash that you’re struggling with? It’s hard to suggest alternatives without knowing your objectives since languages excel in different areas.
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.
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
Those are call applications. Use any language you like. If go/rust is what you know use them. I use rust all the time for things beyond run a bunch of commands and tends to be my go to when I need to process data in any way.
Same. I work primarily in Go and a little bit of Rust these days, but I still throw together a Perl script every year or two to automate something without needing to install something else on the machine or whatnot.
Same. I’m sure python, rust, and all the others are better/cooler/vegan/whatever but perl is what I’m fluent in. More than once have I started to hack together something in python, only to scrap it and start over in perl because I can get it done so much faster. Trust me, my hourly cronjob doesn’t care that it takes half a second more to run. And the UPS doesn’t care that it takes 1mW more to run it. But I care a lot about not dicking around with documentation just to figure out what is pythonic and what isn’t when a shitty perl oneliner will do just fine.
Maybe it’s becuase i grew up on python and bash still seems somewhat alien to me, but any time I’m crafting something with more than three or so nested functions, I use python as a wrapper for bash. Python initiates a bash script, parses the retval, inititates the next bash script from that data, etc.
It’s really unfortunate, that the interaction between Bash and Python is so cumbersome. I would really like a simple Bash-class to invoke simple command strings directly.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
Look at Raku. This seems to be where Raku shines relatively brightly.
I think vanilla perl is also worth looking at if you need the script to be portable
deleted by creator
deleted by creator
deleted by creator
deleted by creator
deleted by creator
i would say lua if possible, but python has more libraries
I’m curious on why you would recommend Lua if available. Is language speed a typical limiting factor for your scripts?
I’m mostly asking since when I was forced to use the language it was nothing but annoyance. The 1 indexing and “if then/for do” will annoy me till my grave.
just for simple tasks, where i need something between the simplicity of bash and the type safety of rust. its just my personal preference when it comes to scripting, although i do believe it should be the first consideration for choosing a user friendly but powerful embedded or config language, like for neovim, especially if performance is a concern, but it will ofc not always be the best option. the 1 index is certainly annoying though, but i would personally rather that than anything to do with python, especially whitespace. the
if...thenandfor...dois the same as bash, so i dont think its that badI was in a similar situation not too long ago.
My criteria for another scripting language included that it should be preinstalled on all target systems (i. e. Debian and Fedora), it should be an interpreted language and it needs to have type safety.
Afterall I settled with Python due to its popularity, its syntax and features (type safety since v3.6, etc.) and the fact that it is preinstalled on many Linux distributions. System components often use Python as well, which means that libraries to interact with the system tend to be included by default.
Myself I know Bash and I know Go.
I would say it’s Python, so I use ChatGPT to code it for me if bash is not enough. If something that I can call “project” instead of “script” - I just use Go for it.
Personally, I don’t feel like it’s worth learning a separate scripting language when you’re comfortable with a full-fledged programming language.
Python, Lua etc. used to be on a whole different level of usability, when compared to C. But compared to modern, high-level languages, the difference is marginal. Not to mention that at least compared to Rust, they start to look rather antique, too, and lack in robust tooling.
If you don’t feel like maintaining a whole git repo, use e.g. rust-script.
Yeah as weird as it sounds to use a “low”-level systems programming language such as Rust. Rust works surprisingly well as “script” language. (And you don’t have to deal with the ugliness of bash, admittedly though, that bash is quite a bit more concise when using a lot of program executions and piping the results etc.)
A shell script can be more concise if you’re doing a lot of shell things. Keeps you from having
os.system()all over the place.Things like “diff the output of two programs” are just more complex in other languages.
I love rust, but replacing my shell scripts with rust is not something I would consider doing any more than I’d consider replacing rust with my shell scripts.
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…
Somewhat of a weird addendum, but I actually only realized, you could port directly over like that, while writing the above comment.
Now I actually tried it on a 22 lines long shell script that I’ve been struggling with, and holy crap, I love it.
Like, I should say that I have always been (and likely will always be) shit at shell scripting. Any time I wanted to do a basic
if, I had to look up how that works.As a result, even those 22 lines were ripe with code duplication and I always felt really unsure about what will actually happen during execution.
Well, rightfully so. While porting over, I realized I had a bug in there, which has been annoying me for a while, but I always thought, well, it is a shitty shell script. I still remember thinking, I should probably not implement it like that, but then leaving it anyways, because I felt it would become unreadable with the shell syntax.
Now it actually feels maintainable, like I can even easily expand on it.
And I have to say that
rust-scriptis really smooth. I barely notice that it’s compiling during the first run after changing the script file, and it’s fully cached afterwards, so it executes instantly.I’ll still have to check for libraries that basically provide such a
run()function/macro for me, but yeah, basically my threshold for not using shell scripts just dropped to any kind of control flow being involved.Yeah the strict type-system of Rust is great at finding issues.
I think when understanding, that bash is basically only programs with parameters (
[is a program that takes all kinds of parameters and as last parameter]) then bash is quite ok for stuff that doesn’t need a lot of algorithms, i.e. passing the in and out from one program to another. But as soon as there’s basic logic, You’ll want to use a fully-fledged programming language.Also the maintainability aspect: You can just start using fancy stuff you never want to use in bash and it can slowly grow into a library or application or something like that.
Btw. I have started a syntax-sugar library/crate that creates typing information for all kinds of programs via the builder-type-state-pattern, so that you don’t always have to look up
manetc. and that it should be more convenient to execute programs (not open sourced yet, and low priority for me as I’m working on various other exciting projects currently)I make bash scripts to automate the configuration of new servers. Stuff like install packages, create users, create groups, configure the database, manage permissions…
I feel like that sort of stuff would be a nightmare to do in high level languages but maybe I’m just too used to bash.
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.
deleted by creator
pyinvoke.
You can create quick and dirty CLIs, invoke shell commands, and have all of python available for things like parsing config files, getting and setting environment variables, and making remote REST calls.
Totally second this.
But I 'd like to recommend starting with subprocess module which is built-in. Then go ahead and see what the extensions have to offer… There are other that may come handy, like Typer from Tiangolo, and Fire from Google.
I’ve used C# in the past. There’s a tool called dotnet-script that lets you run csharp files as scripts without having to compile.
It does require you to install dotnet though.
But tbh it’s pretty easy to just chuck an executable together.
What are you trying to achieve in Bash that you’re struggling with? It’s hard to suggest alternatives without knowing your objectives since languages excel in different areas.
deleted by creator
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.
You could look at logrotate if you don’t want to do something custom
As @damium@programming.dev says you may be able to do this with
findcommand. 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
findcommand also has a-deleteflag.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
My personal favourite remains perl for anything text oriented or for simple-ish orchestration.
I love Raku (formerly perl 6) for this purpose as well.
Those are call applications. Use any language you like. If go/rust is what you know use them. I use rust all the time for things beyond run a bunch of commands and tends to be my go to when I need to process data in any way.
I still reach for Perl when bash isn’t enough.
Same. I work primarily in Go and a little bit of Rust these days, but I still throw together a Perl script every year or two to automate something without needing to install something else on the machine or whatnot.
Same. I’m sure python, rust, and all the others are better/cooler/vegan/whatever but perl is what I’m fluent in. More than once have I started to hack together something in python, only to scrap it and start over in perl because I can get it done so much faster. Trust me, my hourly cronjob doesn’t care that it takes half a second more to run. And the UPS doesn’t care that it takes 1mW more to run it. But I care a lot about not dicking around with documentation just to figure out what is pythonic and what isn’t when a shitty perl oneliner will do just fine.
Maybe it’s becuase i grew up on python and bash still seems somewhat alien to me, but any time I’m crafting something with more than three or so nested functions, I use python as a wrapper for bash. Python initiates a bash script, parses the retval, inititates the next bash script from that data, etc.
It’s really unfortunate, that the interaction between Bash and Python is so cumbersome. I would really like a simple Bash-class to invoke simple command strings directly.
It’s pretty close already. I forget where I cribbed the technique from, but I embed python functions into my scripts very often…
E.g. see here
Try NuShell