Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #256320 > unrolled thread

should CLI have a nice UI today?

Back to article view | Back to linux.debian.user

Contents

  should CLI have a nice UI today? coreyh@free.fr - 2023-03-24 12:40 +0100
    Re: should CLI have a nice UI today? Jude DaShiell <jdashiel@panix.com> - 2023-03-24 12:50 +0100
    Re: should CLI have a nice UI today? Dan Ritter <dsr@randomstring.org> - 2023-03-24 13:00 +0100
      Re: should CLI have a nice UI today? Tom <tom@virta.be> - 2023-03-24 17:00 +0100
        Re: should CLI have a nice UI today? Javier Barroso <javibarroso@gmail.com> - 2023-03-25 23:40 +0100
      Re: should CLI have a nice UI today? Tom <tom@virta.be> - 2023-03-24 17:10 +0100
    Re: should CLI have a nice UI today? Richmond <dnomhcir@gmx.com> - 2023-03-24 16:20 +0100
    Re: should CLI have a nice UI today? davidson <davidson@freevolt.org> - 2023-03-24 21:40 +0100
      Re: should CLI have a nice UI today? davidson <davidson@freevolt.org> - 2023-03-25 00:20 +0100
    Re: should CLI have a nice UI today? Stefan Monnier <monnier@iro.umontreal.ca> - 2023-03-24 22:30 +0100
      Re: should CLI have a nice UI today? Stefan Monnier <monnier@iro.umontreal.ca> - 2023-03-24 22:50 +0100
      Re: should CLI have a nice UI today? <tomas@tuxteam.de> - 2023-03-25 07:40 +0100
    Re: should CLI have a nice UI today? <tomas@tuxteam.de> - 2023-03-25 11:10 +0100
      Re: should CLI have a nice UI today? Stefan Monnier <monnier@iro.umontreal.ca> - 2023-03-29 16:00 +0200
        Re: should CLI have a nice UI today? <tomas@tuxteam.de> - 2023-03-29 16:10 +0200
          Re: should CLI have a nice UI today? Nicolas George <george@nsup.org> - 2023-03-29 16:30 +0200
            Re: should CLI have a nice UI today? Erwan David <erwan@rail.eu.org> - 2023-03-29 16:50 +0200
              Re: should CLI have a nice UI today? Nicolas George <george@nsup.org> - 2023-03-29 17:10 +0200
            Re: should CLI have a nice UI today? debian-user@howorth.org.uk - 2023-03-30 13:10 +0200
          Re: should CLI have a nice UI today? The Wanderer <wanderer@fastmail.fm> - 2023-03-29 16:50 +0200
            Re: should CLI have a nice UI today? Nicolas George <george@nsup.org> - 2023-03-29 17:20 +0200
              Re: should CLI have a nice UI today? debian-user@howorth.org.uk - 2023-03-30 16:50 +0200
                Re: should CLI have a nice UI today? Dan Ritter <dsr@randomstring.org> - 2023-03-30 17:40 +0200
                Re: should CLI have a nice UI today? Stefan Monnier <monnier@iro.umontreal.ca> - 2023-03-31 03:50 +0200
    Re: should CLI have a nice UI today? Emanuel Berg <incal@dataswamp.org> - 2023-03-30 07:50 +0200
    Re: should CLI have a nice UI today? David Christensen <dpchrist@holgerdanske.com> - 2023-03-30 09:30 +0200

Page 1 of 2  [1] 2  Next page →

#256320 — should CLI have a nice UI today?

Hello,

Should CLI (command line interface) have a nice UI library?
today web dev has so many libraries that make web pages with 
rich/colorful interactive views.
But CLI is still in dull mode. That should be improved in these days.
for example, run "df -h" we got the statistics with plain text. But web 
statistics for cloud storage (GCP,AWS etc) are chart like, which give 
people more intuitive feeling.

Thanks
Corey H.

[toc] | [next] | [standalone]

#256321

Ansi gets used to make the eye candy then that ansi breaks screen reader
accessibility with cli screen readers.  No thank you!


-- Jude <jdashiel at panix dot com> "There are four boxes to be used in
defense of liberty: soap, ballot, jury, and amo. Please use in that
order." Ed Howdershelt 1940.

On Fri, 24 Mar 2023, coreyh@free.fr wrote:

> Hello,
>
> Should CLI (command line interface) have a nice UI library?
> today web dev has so many libraries that make web pages with rich/colorful
> interactive views.
> But CLI is still in dull mode. That should be improved in these days.
> for example, run "df -h" we got the statistics with plain text. But web
> statistics for cloud storage (GCP,AWS etc) are chart like, which give people
> more intuitive feeling.
>
> Thanks
> Corey H.
>
>

[toc] | [prev] | [next] | [standalone]

#256322

coreyh@free.fr wrote: 
> Should CLI (command line interface) have a nice UI library?

There are many. The generic underlying library is usually
ncurses. On top of that are more libraries than there are
languages.

> But CLI is still in dull mode. That should be improved in these days.
> for example, run "df -h" we got the statistics with plain text. But web
> statistics for cloud storage (GCP,AWS etc) are chart like, which give people
> more intuitive feeling.

df and du need to work on every system, even teletypes. You can
install the ncdu package or gdu https://github.com/dundee/gdu if
you want something fancier.

-dsr-

[toc] | [prev] | [next] | [standalone]

#256325

>> Should CLI (command line interface) have a nice UI library?
> 
> There are many. The generic underlying library is usually
> ncurses.

But it needs to be stressed that there are many. For Python there is 
Textualize [1], for Go there is Charm [2], rust has a TUI crate [3] 
among other options.

Also, OP might be interested in this list of "Modern Unix" tools. [4]

Cheers,
Tom

[1] https://www.textualize.io
[2] https://github.com/charmbracelet
[3] https://docs.rs/tui/latest/tui/
[4] https://github.com/ibraheemdev/modern-unix

[toc] | [prev] | [next] | [standalone]

#256373

[Multipart message — attachments visible in raw view] — view raw

Hi,

El vie., 24 mar. 2023 16:57, Tom <tom@virta.be> escribió:

>
> >> Should CLI (command line interface) have a nice UI library?
> >
> > There are many. The generic underlying library is usually
> > ncurses.
>
> But it needs to be stressed that there are many. For Python there is
> Textualize [1], for Go there is Charm [2], rust has a TUI crate [3]
> among other options.
>
> Also, OP might be interested in this list of "Modern Unix" tools. [4]
>
> Cheers,
> Tom
>
> [1] https://www.textualize.io
> [2] https://github.com/charmbracelet
> [3] https://docs.rs/tui/latest/tui/
> [4] https://github.com/ibraheemdev/modern-unix


> I would add awesome-shell list:
https://github.com/alebcay/awesome-shell

Regards

[toc] | [prev] | [next] | [standalone]

#256326

I forgot to attribute Dan's writing, and shouldn't have trimmed his 
words as much, after all mentioning exactly the kind of libraries I 
listed. Apologies for the fuss and redo:

On 3/24/23 12:42, Dan Ritter wrote:
 > coreyh@free.fr wrote:>> Should CLI (command line interface) have a 
nice UI library?
 >
 > There are many. The generic underlying library is usually
 > ncurses. On top of that are more libraries than there are
 > languages.

But it needs to be stressed that there are many. For Python there is
Textualize [1], for Go there is Charm [2], rust has a TUI crate [3]
among other options.

Also, OP might be interested in this list of "Modern Unix" tools. [4]

Cheers,
Tom

[1] https://www.textualize.io
[2] https://github.com/charmbracelet
[3] https://docs.rs/tui/latest/tui/
[4] https://github.com/ibraheemdev/modern-unix

[toc] | [prev] | [next] | [standalone]

#256324

coreyh@free.fr writes:

> Hello,
>
> Should CLI (command line interface) have a nice UI library?
> today web dev has so many libraries that make web pages with
> rich/colorful interactive views.
> But CLI is still in dull mode. That should be improved in these days.
> for example, run "df -h" we got the statistics with plain text. But
> web statistics for cloud storage (GCP,AWS etc) are chart like, which
> give people more intuitive feeling.
>
> Thanks
> Corey H.

I was very impressed with the signal meter in nmtui which I had not used
before until yesterday. It has those chunky graphic characters like
Teletext used to be. This sort of thing (I can't do it justice):

🬵🬻

[toc] | [prev] | [next] | [standalone]

#256333

On Fri, 24 Mar 2023 coreyh@free.fr wrote:
> Hello,
>
> Should CLI (command line interface) have a nice UI library?

The teletype (whether virtualised or not) and shells which constitute
that "CLI" are interfaces designed for a purpose.

> today web dev has so many libraries that make web pages with
> rich/colorful interactive views.

The web browser is also an interface designed for a purpose.

A different purpose.

> But CLI is still in dull mode.

No sweetie, it really isn't. Please get a clue.

> That should be improved in these days.

Even venerable tools have been, can be, and will be improved. My
money's on those improvements coming predominantly from people who
recognise what the tools are for.

Good luck with your future projects, my friend.

Choose them wisely.

-- 
Hackers are free people. They are like artists. If they are in a good
mood, they get up in the morning and begin painting their pictures.
-- Vladimir Putin

[toc] | [prev] | [next] | [standalone]

#256344

On Fri, 24 Mar 2023 davidson wrote:
> On Fri, 24 Mar 2023 coreyh@free.fr wrote:
>> Hello,
>> 
>> Should CLI (command line interface) have a nice UI library?
>
> The teletype (whether virtualised or not) and shells which constitute
> that "CLI" are interfaces designed for a purpose.

Speaking of that purpose, at around the half-hour mark in this video,
Ken Thompson describes the genesis of the unix pipe mechanism:

   Ken Thompson interviewed by Brian Kernighan
   (at the Vintage Computer Federation in 2019)
   https://www.youtube.com/watch?v=EY6q5dv_B-o

You might notice how relatively animated he becomes, talking about it
over the course of 5 minutes:

   https://www.youtube.com/watch?v=EY6q5dv_B-o&t=30m15s

>> today web dev has so many libraries that make web pages with
>> rich/colorful interactive views.
>
> The web browser is also an interface designed for a purpose.
>
> A different purpose.

A purpose which (in the case of firefox) apparently does not include
exporting the entire browser configuration to a plain text file so
that we can analyse and transform it with the full orchestra of
text-processing tools.

Personally, this baffles me.

>> But CLI is still in dull mode.
>
> No sweetie, it really isn't. Please get a clue.

To be more specific, composing processes is fun, which is the opposite
of dull.

>> That should be improved in these days.
>
> Even venerable tools have been, can be, and will be improved. My
> money's on those improvements coming predominantly from people who
> recognise what the tools are for.
>
> Good luck with your future projects, my friend.
>
> Choose them wisely.

Because life is short.

Also, in the meantime do play and have fun. For the same reason.

-- 
Hackers are free people. They are like artists. If they are in a good
mood, they get up in the morning and begin painting their pictures.
-- Vladimir Putin

[toc] | [prev] | [next] | [standalone]

#256335

> Should CLI (command line interface) have a nice UI library?

I don't understand the question.  A library that does what?
"Nice" in which respect?

> today web dev has so many libraries that make web pages with rich/colorful
> interactive views.

Not sure how that's relevant to a UI library for a CLI.

> But CLI is still in dull mode. That should be improved in these days.
> for example, run "df -h" we got the statistics with plain text.  But web
> statistics for cloud storage (GCP,AWS etc) are chart like, which give people
> more intuitive feeling.

Do you mean CLI tools should be able to generate&display images?
That could be useful, and indeed xterm and friends nowadays are able to
display images so it's possible, but I suspect it's just easier to have
CLI tools generate JPEG files and then display them in
a separate window.

But maybe it's easier to go the other way: look for a GUI that can be
conveniently controlled from a "command line" or some such combination.
There's a lot of work in the general vicinity.  I think Jupiter could
qualify for some cases, Emacs for others, or you could use the
Javascript console of Firefox for that as well.


        Stefan

[toc] | [prev] | [next] | [standalone]

#256337

> There's a lot of work in the general vicinity.  I think Jupiter could
                                                          ^^^^^^^
                                                          Jupyter

-- Stefan

[toc] | [prev] | [next] | [standalone]

#256358

[Multipart message — attachments visible in raw view] — view raw

On Fri, Mar 24, 2023 at 05:26:07PM -0400, Stefan Monnier wrote:
> > Should CLI (command line interface) have a nice UI library?
> 
> I don't understand the question.  A library that does what?
> "Nice" in which respect?
> 
> > today web dev has so many libraries that make web pages with rich/colorful
> > interactive views.
> 
> Not sure how that's relevant to a UI library for a CLI.
> 
> > But CLI is still in dull mode. That should be improved in these days.
> > for example, run "df -h" we got the statistics with plain text.  But web
> > statistics for cloud storage (GCP,AWS etc) are chart like, which give people
> > more intuitive feeling.
> 
> Do you mean CLI tools should be able to generate&display images?
> That could be useful, and indeed xterm and friends nowadays are able to
> display images so it's possible, but I suspect it's just easier to have
> CLI tools generate JPEG files and then display them in
> a separate window.
> 
> But maybe it's easier to go the other way: look for a GUI that can be
> conveniently controlled from a "command line" or some such combination.
> There's a lot of work in the general vicinity.  I think Jupiter could
> qualify for some cases, Emacs for others, or you could use the
> Javascript console of Firefox for that as well.

After a detour around whiptail I ended up full-circle with Tcl/Tk.
It is still the nicest, smallest self-contained graphical toolkit
enabling one to wrap some GUI around CLI programs. The whole pack
is one or two orders of magnitude smaller than some web browser
monstrosity and much easier to extend, handle and embed.

The language (Tcl) may be a bit alien at first, but all in all
I think wrapping one's head around a "modern" toolkit programming
interface (à la Gtk or Qt) is still at least one order of magnitude
less fun than that.

Why is it that complexity takes over and we end up painting
ourselves into corners? Then, corporate folks ramble about
"path dependencies" and things, instead of acknowledging that
we humans sometimes just aren't good at taking decisions ;-)

But perhaps that's just me.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#256362

[Multipart message — attachments visible in raw view] — view raw

On Sat, Mar 25, 2023 at 09:13:22AM +0100, DdB wrote:
> Am 24.03.2023 um 12:32 schrieb coreyh@free.fr:
> > Hello,
> > 
> > Should CLI (command line interface) have a nice UI library?
> > today web dev has so many libraries that make web pages with
> > rich/colorful interactive views.

[...]

> Well, how do you call messages, that provoke troll replies?

[...]

I think you are being too harsh here. Such a question may come
genuinely from someone who hasn't experienced the power of the
CLI, which, once you've taken the firs step gently takes you
to small one-liners, little loops and bigger and bigger programs.

It has this seamless "growth path" which helps and entices
its users to get better, something I miss from most GUIs, which
rather tend to degrade the user to a click machine. I don't
know whether this is inherent to GUIs or just the current
"social convention" underlying actual GUIs. One might argue
that corporations having promoted the first widespread GUIs
(Microsoft, Apple, etc) have some interest in keeping their
users dependent.

Whatever.

But what the OP gets right is: this "first step" to be taken
is a steep one (I've seen more than enough smart people fight
with that). I wish we had the stamina and creativity to help
people over that "first step", and having some kind of low
level GUI with a soft transition to CLI could be really a
helpful tool there.

That wouldn't be totally new. In the late 1970ies and early
1980ies (the times of Scheme, Smalltalk and so on) there was
this idea that software had to have a pedagogical component
enabling their users to "grow" if they wished so. Smalltalk's
GUI was composable in ways very few GUIs are today, showing
off characteristics you only find in CLIs these days.

What happened to this?

Anyway, back to the topic: I think you are being unjust by
calling troll on this one. I may be wrong, but I recommend
applying Hanlon's razor.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#256510

> I think you are being too harsh here. Such a question may come
> genuinely from someone who hasn't experienced the power of the
> CLI, which, once you've taken the firs step gently takes you
> to small one-liners, little loops and bigger and bigger programs.
>
> It has this seamless "growth path" which helps and entices
> its users to get better, something I miss from most GUIs, which
> rather tend to degrade the user to a click machine. I don't
> know whether this is inherent to GUIs or just the current
> "social convention" underlying actual GUIs.

I think it's the same underlying reasons why programming languages are
almost universally represented as text: maybe it's just because of habit
or "social convention", but I think there's something more fundamental
at play, which make it very hard to make non-textual programming
languages (and maybe even formal systems in general).


        Stefan

[toc] | [prev] | [next] | [standalone]

#256511

[Multipart message — attachments visible in raw view] — view raw

On Wed, Mar 29, 2023 at 09:51:13AM -0400, Stefan Monnier wrote:
> > I think you are being too harsh here. Such a question may come
> > genuinely from someone who hasn't experienced the power of the
> > CLI, which, once you've taken the firs step gently takes you
> > to small one-liners, little loops and bigger and bigger programs.
> >
> > It has this seamless "growth path" which helps and entices
> > its users to get better, something I miss from most GUIs, which
> > rather tend to degrade the user to a click machine. I don't
> > know whether this is inherent to GUIs or just the current
> > "social convention" underlying actual GUIs.
> 
> I think it's the same underlying reasons why programming languages are
> almost universally represented as text: maybe it's just because of habit
> or "social convention", but I think there's something more fundamental
> at play, which make it very hard to make non-textual programming
> languages (and maybe even formal systems in general).

Perhaps roughly 3k to 4k years of storing, transmitting and retrieving
information in written form have a part in it.

It may be a social convention, but by now it runs so deep that I'm
convinced you'll find epigenetic traces of it in us humans.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#256512

tomas@tuxteam.de (12023-03-29):
> Perhaps roughly 3k to 4k years of storing, transmitting and retrieving
> information in written form have a part in it.
> 
> It may be a social convention, but by now it runs so deep that I'm
> convinced you'll find epigenetic traces of it in us humans.

Or perhaps those 3-4K years of storing information have selected a
format that is close to the best possible with the limitations of our
brains, our eyes and our hands.

Keyboards are roughly 150 years old: it is possible we find some
improvement on the way they are designed that makes entering data more
efficient.

On the other hand, computers have not changed the fact that data enters
us mostly as images and sound, so I predict it is unlikely we find means
significantly more efficient than reading.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#256513

Le 29/03/2023 à 16:24, Nicolas George a écrit :
> tomas@tuxteam.de (12023-03-29):
>> Perhaps roughly 3k to 4k years of storing, transmitting and retrieving
>> information in written form have a part in it.
>>
>> It may be a social convention, but by now it runs so deep that I'm
>> convinced you'll find epigenetic traces of it in us humans.
> 
> Or perhaps those 3-4K years of storing information have selected a
> format that is close to the best possible with the limitations of our
> brains, our eyes and our hands.
> 
> Keyboards are roughly 150 years old: it is possible we find some
> improvement on the way they are designed that makes entering data more
> efficient.
> 
> On the other hand, computers have not changed the fact that data enters
> us mostly as images and sound, so I predict it is unlikely we find means
> significantly more efficient than reading.
> 
> Regards,
> 

and do not forget that CLI is what we use in degraded conditions, eg 
when there is no way to get graphics and colors (text, or <insert your 
favorite virtualisation solution here> console)

So we must not depend on graphical capacities to be available

[toc] | [prev] | [next] | [standalone]

#256515

Erwan David (12023-03-29):
> and do not forget that CLI is what we use in degraded conditions, eg when
> there is no way to get graphics and colors (text, or <insert your favorite
> virtualisation solution here> console)
> 
> So we must not depend on graphical capacities to be available

I do not think this is a good argument: nothing forces us to use the
same tools when we have comfortable screens and keyboards and more at
our disposal than when we do not. Of course, we need some tools to work
in limited circumstances, but we do not have to use these tools every
day.

You do what you will, but personally I will keep using zsh and its
features, I will not make /bin/dash my default shell just because I
sometimes have to connect to devices where it is the only shell. And if
that means my finger will try zsh automatisms when I am on these
devices, so be it.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#256544

Nicolas George <george@nsup.org> wrote:
> tomas@tuxteam.de (12023-03-29):
> > Perhaps roughly 3k to 4k years of storing, transmitting and
> > retrieving information in written form have a part in it.
> > 
> > It may be a social convention, but by now it runs so deep that I'm
> > convinced you'll find epigenetic traces of it in us humans.  
> 
> Or perhaps those 3-4K years of storing information have selected a
> format that is close to the best possible with the limitations of our
> brains, our eyes and our hands.
> 
> Keyboards are roughly 150 years old: it is possible we find some
> improvement on the way they are designed that makes entering data more
> efficient.
> 
> On the other hand, computers have not changed the fact that data
> enters us mostly as images and sound, so I predict it is unlikely we
> find means significantly more efficient than reading.

Hmm, I suppose Neuralink et al might disagree with you. Only partly in
jest :)

[toc] | [prev] | [next] | [standalone]

#256514

[Multipart message — attachments visible in raw view] — view raw

On 2023-03-29 at 10:09, tomas@tuxteam.de wrote:

> On Wed, Mar 29, 2023 at 09:51:13AM -0400, Stefan Monnier wrote:
> 
>>> I think you are being too harsh here. Such a question may come 
>>> genuinely from someone who hasn't experienced the power of the 
>>> CLI, which, once you've taken the firs step gently takes you to
>>> small one-liners, little loops and bigger and bigger programs.
>>> 
>>> It has this seamless "growth path" which helps and entices its
>>> users to get better, something I miss from most GUIs, which 
>>> rather tend to degrade the user to a click machine. I don't know
>>> whether this is inherent to GUIs or just the current "social
>>> convention" underlying actual GUIs.
>> 
>> I think it's the same underlying reasons why programming languages
>> are almost universally represented as text: maybe it's just because
>> of habit or "social convention", but I think there's something more
>> fundamental at play, which make it very hard to make non-textual
>> programming languages (and maybe even formal systems in general).
> 
> Perhaps roughly 3k to 4k years of storing, transmitting and
> retrieving information in written form have a part in it.
> 
> It may be a social convention, but by now it runs so deep that I'm 
> convinced you'll find epigenetic traces of it in us humans.

I think it's plausible/probable that it's not so much about the format
itself, but about the data/meaning/information attached to that format.

Text has much more *nuance* and *detail* attached to it than any
non-text-based programming structure I've ever run across, while also
having more *formality* and *precision* attached to it than e.g.
spoken-word conversations (which have a lot more nuance, because of the
added information channels of tone and inflection and the like).

If you can contrive another format for representing the user's intention
that enables comparable or greater amounts of expressiveness, while not
sacrificing much if any precision or rigor, I suspect that that format
might be able to equal or surpass text for programming, etc., purposes.

Good luck with doing that, though; if such a thing were practical, it
would very likely have been invented long since. Unless it only becomes
practical with a technology that's only become available relatively
recently, but unless e.g. the recent forays into "AI" represent such a
thing, I'm not sure what candidates for such a thing there might be.
(And even those "AI"s are interacting with people through text.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web