Sadly, on macOS's Homebrew, rc comes without readline. I don't really want to install pkgsrc on this computer just to have that. I wonder if there is an easy fix.

(27-03-2023, 06:35 PM)jkl Wrote: Sadly, on macOS's Homebrew, rc comes without readline. I don't really want to install pkgsrc on this computer just to have that. I wonder if there is an easy fix.

I can only think on two workarounds: call rc through rlwrap if you're running on a regular terminal, or use 9term and rely on its line editing system. The latter is the closest you get to plan9 regarding line editing on the shell.

9term is a rather good idea which I did not have myself, thank you. :)
rlwrap would probably work too. I'll see what I can do with it...

edit:

Quote:rlwrap: warning: rlwrap appears to do nothing for rc, which asks for
single keypresses all the time. Don't you need --always-readline
and possibly --no-children? (cf. the rlwrap manpage)

Well... :)

edit: Had to use Git for the best option (namely, just use Byron's rc and enable readline (and the built-in history!) myself).


Works. (If readline can't be found, setting LDFLAGS and CPPFLAGS to point to readline's /lib/ and /include/ folders fixes it.)

Finally, a sane shell again. I also used this opportunity to figure out how to make rc case-insensitive when compiled with readline:


Good enough!

rc seems to get rid of autotools and no longer has the history only as an optional feature. Good.
https://github.com/rakitzis/rc/commit/0e...3110fdec57

Fish because I'm a filthy casual who doesn't write shell scripts anymore.

You don't need to use the same interactive shell as you use for your scripts. Never had, never will.

(12-06-2023, 05:30 PM)jkl Wrote: You don't need to use the same interactive shell as you use for your scripts. Never had, never will.

I know. I just haven't bothered with shell scripts because I moved to "normal people" distros like Fedora with GNOME so I don't faff about terminals like I used to. Fish just helps when I'm having to manually do commands anyway like hosting WEBrick for Jekyll. Everything else I got an Emacs frontend for or is moot using GNOME (aka no more X11 shenanigans just to make the window manager do things).

Back when I was on Void Linux with herbstluftwm or cwm, majority of my shell scripts were just to configure my window manager and handle any app-specific issues in that environment. Now those aren't necessary so...why bother? 🤷🏻‍♂️

zsh for the win! i use it with fzf-tab, powerlevel10k, and fish-style autosuggestions.

just standard bash.

bash is not a standard.

Yep, poor choice of words on my side. I meant plain, boring etc.

Ah. Why do you use boring software? ;-)

It's installed by default and I'm too lazy to change it.

(11-09-2023, 05:38 AM)Dworin Wrote: It's installed by default and I'm too lazy to change it.

No prob, just wait for the next shellshock bug so someone can do it for you remotely ;)

I use fish because it is easy, but i would better like to see a drastical reform in cli/tui shells, something along the lines of nushell, but graphically.

Graphically? Do you need more pictures?

(13-09-2023, 11:35 AM)jkl Wrote: Graphically? Do you need more pictures?

CLI tools are cool, but they are constrained by the features provided by the console, so the lowest common dominator is the 80x24 resolution, which allows the user to use the well known programs to restore the system in emergency. This can means life or death in serious situations, so of course it make sense to be able to use those tools even trough a real teletype. But it doesn't means it is the best possible way to do actual work in non-emergency situation.

I know that this might sound heretic, especially on Nixers, but the best possible way to do actual work in a non-emergency situation is not the CLI. This is not related to the inadequacy of the surrounding console window.

(13-09-2023, 06:18 PM)jkl Wrote: I know that this might sound heretic, especially on Nixers, but the best possible way to do actual work in a non-emergency situation is not the CLI. This is not related to the inadequacy of the surrounding console window.

It probably depends on the task.

I like to distinguish between CLI and TUI, by the way, when thinking about questions like this. And between both of them and GUI, which in turn leads to a distinction between rudimentary xt or gtk applications, for example, and full-blown desktop environments. All of which have their place.

(13-09-2023, 06:18 PM)jkl Wrote: I know that this might sound heretic, especially on Nixers, but the best possible way to do actual work in a non-emergency situation is not the CLI. This is not related to the inadequacy of the surrounding console window.

The biggest advantage of GUIs rather than CLIs. You can learn a bit about a program's capabilities by poking around menus. People praise the manpage and yet it's as useless as rifling through a large binder. There's no hyperlinking in a manpage: just grepping back and forth with a plethora of false positive matches. TUIs can come close but are still bogged down by their 80x24 cages.

Even what we consider the "gold standard" of CLIs can be reworked. It can be better. We just stubbornly insist on POSIX like LARPers in front of a DEC machine.

The biggest advantage of CLIs is probably their scriptability.

They're all about the functionality, not the user interface. In fact, I think they're at their best in contexts like a crontab where any output is redirected to a file or /dev/null.

(16-09-2023, 09:56 PM)ckester Wrote: The biggest advantage of CLIs is probably their scriptability.

Then why not both, and have something like what is proposed in these two thread here and here. Scripts that can suddenly become graphical interfaces, or interfaces that can become scriptable. It would be fun to have the classic CLI vs GUI in its own thread though to dive deeper in the topic.

AppleTalk might have been the best example of how to script a GUI application. But I haven't been on an Apple system in years and don't know what they have along those lines now.

AppleTalk's auto-configuration features mostly live on in Bonjour, (GUI) scripting is preferably done with the Automator and Apple's own AppleScript (that resembles Smalltalk): https://en.wikipedia.org/wiki/Automator_(macOS)

Oops, I was thinking of AppleScript not AppleTalk. It's been that long since I've looked at anything Apple. ($$$)

used in the past zsh but now only bash