81–90 of 204 posts
Just because something has been around for a long time it doesn't mean that it's outdated. On the contrary, it means that it's stood the test of time, which is usually a sign of a good design.
Sorry, by outdated I meant not a good fit for today's problems.
(Personally, I use ksh, which, while as bloated as bash, is bloated in more useful ways, and not so gratuitously divergent from plain sh.)
I'm sure we can all agree that the current state of shells needs some work, but I don't think inventing a new one is the right solution. I'm a huge fan of the fish shell, but in the real world, it never seems to be installed across the farm, and convincing the older SysAdmins to install it is more trouble than it's worth. We should be focusing on saner bash defaults, since it's the most common shell in use. We should…
Bash already provides two "modes": when called as `sh` it is more POSIX-compliant, when called as `bash` it allows more bash-specific features and syntax.
Maybe `bash` invocation can remain for backwards compatibility, and a new mode be added (e.g. `sash` for "sane shell") which can be used for breaking changes in the name of safety and sanity.
This opt-in usage would avoid breaking existing scripts; whilst being bundled as part of bash would mitigate some of the chicken-and-egg and paradox of choice. Over time, `/usr/bin/env sash` will appear in more and more guides/tutorials/etc. whilst those using `/usr/bin/env bash` will continue to work, but look a little clunky.
Of course, making such a "sane mode" as part of Bash would make it more high-profile and cause much more NIMBY, politics and bike-shedding than as a standalone project; but if it has a clear, consistent "mission statement" (e.g. "safety over convenience", "consistency over edge-cases", etc.), then maybe it could avoid too much scope creep and benefit from input by lots of very knowledgable experts.
Earlier quoted context omitted.
Please give a single example in shell about spaces, that has not been already addressed. From where do your get that rule?
It's the pareto principle. In this case he means "20% of the problems account for 80% of the trouble" -- albeit somwhat strangely worded.
I write shell daily, and that are not my numbers regarding "spaces on filenames issues", sorry.
Earlier quoted context omitted.
I'm suprised you can't think of problems you currently have with shells. Here is a few of mine: * Once I've started a program, and easy way of sending it to the background if it is taking a while, which sends it's output to some buffer I can refer to later, rather than continuing to spew it all over the screen. * While we are at it, stop spewing the output of multiple programs over the screen, under any circumstances…
issue 1) sounds like you miss nohup, sreen or tmux in front of that long running program. issue 2) usually I don't have one terminal session with multiple programs doing output at the same time, this solves this issue. Just use a new xterm, a new terminal tab, a new screen tab for programs that are going to produce output and stay running. issue 3) I think you refer to files with other special characters, because spa…
Earlier quoted context omitted.
Not sure on why this comment got down-voted. If it's because I did not explain how to do that, there is howto do it: http://mywiki.wooledge.org/BashFAQ/004 If it's because the comment on the given example... $ touch file1 $ ls -l | wc -l 1 $ touch "file 2" $ ls -l | wc -l 2 ... (?) If we were talking about "new lines in file names", or "dashes at the beginning of file names", or code injection through file names, the…
I'm guessing it was down-voted because you keep missing the point. Yes, there are work-arounds for this scenario, but the overhead in remembering the work-arounds is the problem. He's not saying you can't do it, he's saying the problem is that you have to change your setup for edge-cases, which are actually fairly common.
A big problem, is that people that underestimate an unknown technology, does not take the time to learn properly that technology.
Many programmers think they "know" shell (and many beginners), so they don't invert more time and tests, and then they keep facing corner cases, facing known and documented and solved issues, etc...
You are asserting, than learning bash is harder than learning the corner cases of other more advanced languages. Is that what you say? do you think that "bash" has more corner cases than ... (?)
How we can patch that? With a web shell?
Totally true, I've miss totally the point.
I'm sure we can all agree that the current state of shells needs some work, but I don't think inventing a new one is the right solution. I'm a huge fan of the fish shell, but in the real world, it never seems to be installed across the farm, and convincing the older SysAdmins to install it is more trouble than it's worth. We should be focusing on saner bash defaults, since it's the most common shell in use. We should…
We should be focusing on saner bash defaults, since it's the most common shell in use. That kind of work is not glamorous and highly controversial. Ideally there should be some sort of cross distro/OS working group (Debian/Ubuntu, Red Hat, SUSE, FreeBSD, NetBSD, OpenBSD, Mac OS X, etc.), similar to the working groups that standardize the web, where such proposals can be made, voted on and adopted. For example there s…
Like the Austin group, the technical committee that constantly releases updates to POSIX and the Single Unix Specification? http://www.opengroup.org/austin/ http://pubs.opengroup.org/onlinepubs/9699919799/
Earlier quoted context omitted.
issue 1) sounds like you miss nohup, sreen or tmux in front of that long running program. issue 2) usually I don't have one terminal session with multiple programs doing output at the same time, this solves this issue. Just use a new xterm, a new terminal tab, a new screen tab for programs that are going to produce output and stay running. issue 3) I think you refer to files with other special characters, because spa…
The point of issue 1 is that sometimes you don't know that the program will run for a long time. So a way to send a program into the background while it is already running, would be nice.
Earlier quoted context omitted.
ls is not bash wc is not bash And that is a discouraged way to count files in shell script. Still, simply adding -l to ls, could handle spaces correctly (the files count) I insist, spaces are not your enemy, there are much more weird file names for a shell. Shell can handle spaces if used properly.
Not sure on why this comment got down-voted. If it's because I did not explain how to do that, there is howto do it: http://mywiki.wooledge.org/BashFAQ/004 If it's because the comment on the given example... $ touch file1 $ ls -l | wc -l 1 $ touch "file 2" $ ls -l | wc -l 2 ... (?) If we were talking about "new lines in file names", or "dashes at the beginning of file names", or code injection through file names, the…
How about (for example):
$ for i in $(ls | grep 'cheese\|fish' | head -n 5) ...
I'm sure we can all agree that the current state of shells needs some work, but I don't think inventing a new one is the right solution. I'm a huge fan of the fish shell, but in the real world, it never seems to be installed across the farm, and convincing the older SysAdmins to install it is more trouble than it's worth. We should be focusing on saner bash defaults, since it's the most common shell in use. We should…