A little anecdote: there was a case of O(N^2) in readline with long lines. Essentially a bug in the redisplay logic. It affected Bash, mysql/psql, Python, etc.
After having suffered from this for some years, last year that annoyed me enough to start digging into readline to figure out what was causing it. In the end, that prompted Chet Ramey to come up with a fix which looks like it is now being released!
I promised myself that when this one was fixed, I'd look into why most readline shells can go nuts when you resize them - somehow they don't always discover that the line width has changed.
> I promised myself that when this one was fixed, I'd look into why most readline shells can go nuts when you resize them - somehow they don't always discover that the line width has changed.
Possibly related?
> Use pselect(2), if available, to wait for input before calling read(2), so a SIGWINCH can interrupt it, since it doesn't interrupt read(2).
To find the time taken by jobs, it's simplest to just display current time in the prompt. You can quickly look at the time when the job start and the time after job ended.
Except you have to not forget the to refresh the prompt before typing the command after a coffee break or switching terminal tabs, etc. The PS0 solution is much, much better for this use case.
There is way to hook into command execution. And that piece of code you hook in could look at a variable called PS0 and process it the way Bash 4.4 does it now.
This new PS0 might provide a pre-execution hook of its own. If it performs $(....) command substitution (like PS1 does!), it provides a way of executing arbitrary code. If the entire prompt is "$(some-command ...)" and that command produces no output, then you have a de facto pure hook.
You could use PS0 to make your terminal title be "running <name of program>" when a program is running, then "directory <dir name>" when just on a prompt (that might be too busy for some people, but I'd like to know if a program is actively running in the terminal title).
This is really nice if you keep your own history because then the directory stored for commands like cd will be the one it was called from rather than the one it moved you into.
One Readline feature I have been looking forward to:
> c. The editing mode indicators can now be strings and are user-settable (new `emacs-mode-string', `vi-cmd-mode-string' and `vi-ins-mode-string' variables). Mode strings can contain invisible character sequences. Setting mode strings to null strings restores the defaults.
So now I can get the prompt to change color depending on the mode!
OS X has been stuck in 3.2.57 for years due to licensing.
I like being able to SSH into a fresh Linux box and feel at home, but at some point, they'll be so different that I might as well permanently switch to Zsh.
I keep hoping for Apple to adopt Fish, last I heard the guy works there, and it's totally Apple's thing to have its own shell. It would be fun at least.
Realize that if your personal account's shell is pointed into the homebrew installation in /usr/local, and you implode homebrew or wipe /usr/local, you won't be able to start a terminal until your shell is changed or the binary exists. Solving this without Terminal.app being able to launch is a minor annoyance.
If you are able to run a script with #!/bin/sh, and /bin/sh becomes un-executable during the execution of your script, you're definitely having a bad time. :D
I found an "article" that explains this a bit [0], the gist is that the App Store is the sticking point. But why would this be the case? What does bash have to do with the App Store app? And why are they still allowed to distribute 3.2?
Bash 3.2 is distributed under GPL Version 2. Bash 4 is under GPL version 3. (I'll let others discuss the differences and how they might interact with the App Store.)
That doesn't make any sense, App Store has no relation to what Apple distributes as part of macOS.
Apple takes issue with patents-related wording in GPL3 and doesn't want to be subject to GPL3 (while they're OK with GPL2). Hence not distributing GPL3-licensed software.
FWIW fish is great. My only complaint is that you can't use the `ENV_VAR=value` syntax available in bash, but you really just need to prefix with `env`.
Why would you want to multiply by 1 or sum zero? You probably wouldn't need to do it, but computers and scripts aren't so smart as people and always follow code literally. For them is important a language having less irregularities and exceptional rules. If "" is a valid command and you have the syntax "time [COMMAND];", why not allow "time;"?
where cmd happens to be unset. Conceptually, that's a valid script, because `time` standalone is a valid script. No reason it should generate an error.
I'm not sure how wise that is. It doesn't exactly lead to readable scripts. Zsh has had the equivalent feature with the syntax ${(operator)parameter) for over two decades so plenty of time for more operators to be added. It is very powerful but worse than perl for code that looks like line noise.
You obviously missed the point, even when identifying the incongruities of your assessment.
Inspite of that, ANYTHING is better than systemd.
edit: Having something like LLVM as a first class daemon, compared to something like systemd is not even comparable. It's like... evolution. systemd is like taking corporate backwash and trying to clean a pristine pond.
>Inspite of that, ANYTHING is better than systemd.
Not really. It's a great replacement for the mess of init scripts and ad-hoc solutions in traditional unix, and it was an informed decision after many years of deliberations for most distros to adopt it.
Besides this is zero content.
>Having something like LLVM as a first class daemon, compared to something like systemd is not even comparable. It's like... evolution. systemd is like taking corporate backwash and trying to clean a pristine pond.
You keep using this word LLVM. I'm not sure it means what you think it means.
Systemd is not a compiler, it's a system for managing system services and processes.
LLVM is just a set backend libraries for writing compilers, and a collection of some compilers implemented with them.
"Having something like LLVM as a first class daemon" is close to being content free as a statement, especially when that's something's role will be to replace systemd. It's not even wrong, it's meaningless.
In the only way the sentence makes sense "LLVM as a deamon", would be a always-running compiler/server that you pass your programs to it, instead of invoking LLVM as a command line app.
LLVM is obviously not a daemon which is why having it as a daemon would be one point. Even that would have been more flexible, simple, and far less invasive and corruptive.
There was no mess of init scripts. The only mess introduced was through poor integration practices through the introduction of corporate induced timelines and requirements, who then introduced an even worse solution.
I agree that we can do better than systemd, but what do you think LLVM does? How would it even fit into that role. Let's be specific, I want to understand where you are coming from.
The problem is not only with bash, but with entire gnu ecosystem. Bash disable something ONLY when the parent process is EMACS is totally nonsense. Bash should check for some behavior, instead of some technology... because I'm sure other editors can behave similarly when executing bash inside some buffer.
Doing software this way makes bash and emacs working well, but hard to make other softwares interact with both of them... Sublime, acme, micro, and so on can benefit of a better solution. In the same way, other shell should work fine inside emacs (M-x ansi-term).
But software design is not expected here (see downvotes)
After having suffered from this for some years, last year that annoyed me enough to start digging into readline to figure out what was causing it. In the end, that prompted Chet Ramey to come up with a fix which looks like it is now being released!
I promised myself that when this one was fixed, I'd look into why most readline shells can go nuts when you resize them - somehow they don't always discover that the line width has changed.