[HN Gopher] Bashsimplecurses: Simple curses library made in bash...
___________________________________________________________________
Bashsimplecurses: Simple curses library made in bash to draw
terminal interfaces
Author : tambourine_man
Score : 65 points
Date : 2024-07-27 14:23 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| atomicnumber3 wrote:
| This is cool, I've used curses UIs to build various small things
| that need to be a) vaguely easy to use (so, complicated CLIs are
| out. oncalls need to be able to use this at 3am while half their
| brain is still sleeping) and b) accessible over ssh because we
| have secure ssh access to these envs but ~nothing else.
|
| So I love TUIs.
|
| That said, I'm always a little puzzled about why people build
| these libraries in bash. Is it simply curiosity? Maybe, and if
| so, godspeed.
|
| But if it's driven by pragmatism, let me assure the reader that
| if there are limits to the extents I will go to get python
| somewhere instead of writing even a somewhat nontrivial bash
| script, I have yet to find them. Not only is bash just kind of
| really annoying to program in, it's also nearly unethical to
| program in. Let me link the 2 I always link to when someone tells
| me they're "working on" a bash script.
|
| Steam deleted my entire system (empty variable expansion):
| https://github.com/valvesoftware/steam-for-linux/issues/3671
|
| Bumblebee deletes /usr due to space:
| https://www.reddit.com/r/softwaregore/comments/2hsdo6/giant_...
|
| So I warn people: if you use python, you'll categorically avoid
| being the third entry in my list.
| gtirloni wrote:
| Python is available virtually anywhere. I'd also not use Bash
| unless it's a very restricted situation. Every time I'm writing
| a shell script that's more than a page, a sense of imminent
| doom starts to dominate my soul.
| bongodongobob wrote:
| No it isn't. I don't know what kind of infrastructure you
| work on but I can't just go installing python on prod servers
| whenever I want to be able to run some random script.
| catlifeonmars wrote:
| Why are you running random scripts on prod servers? ;) :P
| gumby wrote:
| Sometimes the only way to investigate a problem. How can
| you even write a test case if you don't know what's going
| on?
| layer8 wrote:
| "Python" isn't very well-defined. Which version? Which
| (installed) dependencies?
| panki27 wrote:
| Python also brings a wrapper for curses (atleast under *nix).
|
| Curses in itself needs so much boilerplate that I usually just
| go to the libraries rich or textual instead.
| ndsipa_pomu wrote:
| Both of those are examples of known footguns in BASH and it's
| easy enough to avoid them if you run your BASH scripts through
| ShellCheck and follow the recommendations.
| JNRowe wrote:
| Zsh users get a bundled curses module; see zsh/curses1 in
| zshmodules(1). It is a _very_ thin wrapper, so it works how you
| 'd expect from other uses. There is a tetris implementation using
| zsh/curses that ships with zsh2, and you can use it as a nice
| comparison to the non-curses implementation that also comes with
| zsh3.
|
| I've used zsh/curses a few times to hack together little
| interfaces, and it is quite workable. It makes things far simpler
| once you start reaching for terminfo's capabilities that require
| you to think about state too much. A friend of mine wrote a
| little mblaze4 frontend using it, and it felt like using single
| mailbox mutt with less than a hundred lines of code.
|
| I was expecting the linked project to be a loadable module too
| given that bash also supports them, but it is actually a little
| more interesting to look at given it implements a bunch of the
| behaviour itself on top of tput calls.
|
| 1 https://zsh.sourceforge.io/Doc/Release/Zsh-Modules.html#The-...
|
| 2 https://github.com/zsh-users/zsh/blob/master/Functions/Misc/...
|
| 3 https://github.com/zsh-users/zsh/blob/master/Functions/Misc/...
|
| 4 https://git.vuxu.org/mblaze/about/
| iam-TJ wrote:
| There's some quite impressive and interesting bash (and other
| shell) exploration in the matrix.org "Fun Shell Scripting" room
| from time to time; usually when someone asks an obscure question
| and a few people dive down a rabbit-hole.
|
| One oft overlooked feature is bash supports dynamically loadable
| 'builtins' as shared object modules so it wouldn't take much to
| create a 'proper' wrapper around libncurses.
|
| Debian and derivatives have the package "bash-builtins" that has
| a lot of examples including wrapping/implementing many coreutils
| tools.
| abathur wrote:
| A good example for lulz is https://github.com/zevweiss/booze, a
| FUSE binding for bash.
|
| Aside: I've wondered aloud if we could figure out how to
| systemically compile coreutils into true bash builtins for
| performance benefits in nix builds, but someone did rightly
| point out that builtins can't be completely fungible with a
| separate process in all cases, especially where stuff like
| pipelines are involved. I don't recall the exact details and
| couldn't readily find the conversation but IIRC it had to do
| with signal handling.
|
| Edit: Found the conversation:
| https://gist.github.com/abathur/74e7a63b25b7bbd4a6fa9ad7e728...
| rsync wrote:
| This reminds me of something I have always wanted in the UNIX
| ecosystem:
|
| "topify"
|
| ... which is the word I would use to describe a primitive that
| will take line inputs from stdio and display them in a 'top'
| style output, presumably with curses.
|
| Maybe there is more complication here than I have thought out but
| ... if I can output a standard line with columns I have already
| defined (perhaps in an 'awk' pipeline or whatever) then I would
| like a way to refresh them, in some order.
|
| I am fairly certain this does not exist ...
| jjjzzz wrote:
| You mean "watch"?
| JNRowe wrote:
| There is also viddy1 for a slightly more featureful watch
| alternative, if you're open to a new non-default package.
| Being able to recall old output and search within it can be
| extremely useful.
|
| Admittedly, it isn't quite a drop in replacement, but the
| usage is close enough that even aliasing it is unlikely to
| cause [ _many_ ] problems.
|
| 1 https://github.com/sachaos/viddy/
| rsync wrote:
| "You mean "watch"?"
|
| I'm not sure.
|
| I've been directed to this in the past but I have a vague
| sense that it didn't do what I was looking for.
|
| I will take another look ...
| woodsie wrote:
| Bash with a #!/bin/bash shebang. Typical GNU cultural
| imperialism. "Everyone has a Bash and it's always kept in /bin."
| dspillett wrote:
| And the alternative when you definitely want bash because
| you've used extended non-posix features /bin/sh is not
| guaranteed to have?
|
| Without just using #!/bin/sh (or some trick with env that may
| also not be portable), then having a large fancy function to
| test for current shell identity and tries to search for &
| respawn with something else if that does not seem to be
| suitably compatible?
|
| The project has bash on its name - it is not as if it is
| _pretending_ to be more generic, or written by someone who has
| always had bash linked from /bin/sh and knows no better.
| abathur wrote:
| Presumably: #!/usr/bin/env bash
| tgv wrote:
| #! env bash at least makes it path independent. But I think
| the parent comment is in jest.
| ofalkaed wrote:
| I have a fondness for bash abuse and those odd sort of people who
| get fixated on bash. bed [0] the bash editor is one of my
| favorite examples, always surprised by how short and concise it
| is, far from a great editor but a great exercise and I learned a
| thing or two about the bash way from it.
|
| 0. https://github.com/comfies/bed
| layer8 wrote:
| If you only need simple dialogs, _whiptail_ is usually installed
| on Debian-based systems:
| https://en.wikibooks.org/wiki/Bash_Shell_Scripting/Whiptail
___________________________________________________________________
(page generated 2024-07-27 23:09 UTC)