AI coding assistants promise speed, but do they deliver? Explore data, developer insights, and security risks showing why AI feels faster but often slows production. Learn where tools like Cursor and Claude Code help, and where they fail.
I am sorry, but I am not sure what tells you how Bash “was designed” or not. Perhaps you haven’t yet written anything serious in Bash…
Have you checked out Bash PitFalls at Wooledge, at least?
Bash, or the most shells, including Posix, or even Perl, are some of the most complex languages out there to make a mistake… since there’s no compiler to protect you from, and though legendary but readline may cause the whole terminal go flying, depending on the terminal/terminfo in process…
No, sorry. I absolutely disagree on your stance regarding “shell” for a “bugless” “huge deal” in “real cases”.
The point I’m making is that bash is optimized for quickly writing throwaway code. It doesn’t matter if the code written blows up in some case other than the one you’re using. You don’t need to handle edge cases that don’t apply to the one time that you will run the code. I write lots of bash code that doesn’t handle a bunch of edge cases, because for my one-off use, that edge case doesn’t arise. Similarly, if an LLMs is generating code that misses some edge case, if it’s a situation that will never arise, and that may not be a problem.
EDIT: I think maybe that you’re misunderstanding me as saying “all bash code is throwaway”, which isn’t true. I’m just using it as an example where throwaway code is a very common, substantial use case.
I still don’t get what you mean, sorry. And why Bash and not another shell?
Why not Korn, Ash, Dash, Zsh, Fish, or anything REPL, including PHP, Perl, Node, Python etc.
Should we consider “throwaway” anything that supports interactive mode of your daily driver you chose in your default terminal prompt?
What does “throwaway” code means in the first place?
Yeah, I went back through this reply chain and I couldn’t find any explicit evidence that they’re talking about shell scripting at all, and perhaps think that the “bash programming language” refers to a general style, i.e. “to bash stuff together until it works”.
If you want to actually realize the amount of possible misunderstanding in the current conversation and of what shell scriting is, please do consider joining #bash at Libera IRC. Please do also mention the word “throwaway” in the rooms! Since there’s literally no understanding on what you mean still, sorry. It does not feel like you have a significant enough understanding of the subjects raised.
For a very simple example, there are literally no documentation regarding certain cases you’ll encounter in Bash’s built-ins even, unless you actually encounter it or learn from Bash’s very source code, like read built-in. Not to mention shenanigans in shell logics for inter-process communication (IPC), file-descriptors, environment variables like PWD, exported functions’ BASH_FUNC_, pipes, etc.
I am sorry, but I am not sure what tells you how Bash “was designed” or not. Perhaps you haven’t yet written anything serious in Bash…
Have you checked out Bash PitFalls at Wooledge, at least?
Bash, or the most shells, including Posix, or even Perl, are some of the most complex languages out there to make a mistake… since there’s no compiler to protect you from, and though legendary but readline may cause the whole terminal go flying, depending on the terminal/terminfo in process…
No, sorry. I absolutely disagree on your stance regarding “shell” for a “bugless” “huge deal” in “real cases”.
The point I’m making is that bash is optimized for quickly writing throwaway code. It doesn’t matter if the code written blows up in some case other than the one you’re using. You don’t need to handle edge cases that don’t apply to the one time that you will run the code. I write lots of bash code that doesn’t handle a bunch of edge cases, because for my one-off use, that edge case doesn’t arise. Similarly, if an LLMs is generating code that misses some edge case, if it’s a situation that will never arise, and that may not be a problem.
EDIT: I think maybe that you’re misunderstanding me as saying “all bash code is throwaway”, which isn’t true. I’m just using it as an example where throwaway code is a very common, substantial use case.
I still don’t get what you mean, sorry. And why Bash and not another shell?
Why not Korn, Ash, Dash, Zsh, Fish, or anything REPL, including PHP, Perl, Node, Python etc.
Should we consider “throwaway” anything that supports interactive mode of your daily driver you chose in your default terminal prompt?
What does “throwaway” code means in the first place?
I… think they might be misusing the word “bash”? Maybe?
Yeah, I went back through this reply chain and I couldn’t find any explicit evidence that they’re talking about shell scripting at all, and perhaps think that the “bash programming language” refers to a general style, i.e. “to bash stuff together until it works”.
I chose it for my example because I happen to use it. You could use another shell, sure.
Interactive mode is a good case for throwaway code, but one-off scripts would also work.
If you want to actually realize the amount of possible misunderstanding in the current conversation and of what shell scriting is, please do consider joining
#bashat Libera IRC. Please do also mention the word “throwaway” in the rooms! Since there’s literally no understanding on what you mean still, sorry. It does not feel like you have a significant enough understanding of the subjects raised.For a very simple example, there are literally no documentation regarding certain cases you’ll encounter in Bash’s built-ins even, unless you actually encounter it or learn from Bash’s very source code, like
readbuilt-in. Not to mention shenanigans in shell logics for inter-process communication (IPC), file-descriptors, environment variables likePWD, exported functions’BASH_FUNC_, pipes, etc.