Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building the Future of the Command Line

github.com

Post reply on HN
Print view View original

41–50 of 75 posts

Re: Building the Future of the Command Line

#41

Post by abathur »

mschrage wrote: post #34
abathur wrote: post #10

Earlier quoted context omitted.

I have a hard time imagining how we get out of the gravity well of CLI programs handling their own parsing. A tool I write has a use-case for understanding the syntax of at least ~common CLI tools well enough to pick out args that will be other executables (sudo cat, find blah -exec...), so I have been idly pondering whether there's a humane, declarative, descriptive grammar that can express nearly all CLI interfaces…

You might find Fig completion specs useful for this: https://github.com/withfig/autocomplete

Completions have in general been of interest, though the shell-specific completions I've looked at so far were all too dynamic.

I'd forgotten all about Fig since I saw your launch post here last year, so thanks for reminder. (I don't think I had quite started to work on parsing specific external commands, yet, so it wouldn't have clicked at the time. Was still focused on just identifying the likely presence of exec in the executables.)

Are you familiar with the parse code? Are you handling painful stuff like combined short flags with a trailing option? (If I ferreted out some of the more painful cases I've had to wrangle, I am curious if you'd have a gut sense of whether your approach handles it. Would you mind if I reach out? I am working on this for https://github.com/abathur/resholve)

Re: Building the Future of the Command Line

#42

Post by brujoand »

Kukumber wrote: post #11

"your server needs a GPU and an i5 to use our shell, as it provides a graphical interface and some shader animation because that's what attract the money people, they want shiny stuff y'know" This trend of "new modern shells" that runs and start as slow as some javascript code (powershell) needs to stop People forgot what shells are for, and what scripting is for

Agree, I actually wrote a multiline dual sided powerline inspired prompt with modular segments (info from git/pyenv etc) in bash exactly to get these fancy shiny things without having to introduce new dependencies. I log into any server, pull my config and bob’s your uncle. (Btw, that expression is so weird). Ofc, to have the powerline look I would need custom fonts on the client terminal but I usually don’t enable them as I’ve added other “themes” instead.

Re: Building the Future of the Command Line

#43

Post by mormegil »

oceanplexian wrote: post #38

> One of its modules attempts to translate natural language requests into the correct shell commands and syntax. For example, if you typed “compress Documents folder,” CLAI will recommend the corresponding Tar command. This is such a bad idea I don’t know where to start. Shell commands are a dangerous, but precise tool, somewhat like using a scalpel or a surgical tool. Dumbing it down so it can “guess what you want i…

Exactly.

> Warren Teitelman originally wrote DWIM to fix his typos and spelling errors, so it was somewhat idiosyncratic to his style, and would often make hash of anyone else's typos if they were stylistically different. Some victims of DWIM thus claimed that the acronym stood for ‘Damn Warren’s Infernal Machine!'.

> In one notorious incident, Warren added a DWIM feature to the command interpreter used at Xerox PARC. One day another hacker there typed delete *$ to free up some disk space. (The editor there named backup files by appending $ to the original file name, so he was trying to delete any backup files left over from old editing sessions.) It happened that there weren't any editor backup files, so DWIM helpfully reported *$ not found, assuming you meant 'delete *'. It then started to delete all the files on the disk! The hacker managed to stop it with a Vulcan nerve pinch after only a half dozen or so files were lost.

The Jargon File http://www.catb.org/jargon/html/D/DWIM.html

Re: Building the Future of the Command Line

#44

Post by gorgoiler »

I love the future that fzf has given us. So many new ideas for selecting and viewing lines of space delimited records — the bread and butter of the shell — are possible with fzf and you get to build them in the traditional of small composable tools.

Junegunn Choi is really talented designer. More please.

Re: Building the Future of the Command Line

#45

Post by none_to_remain »

oceanplexian wrote: post #38

> One of its modules attempts to translate natural language requests into the correct shell commands and syntax. For example, if you typed “compress Documents folder,” CLAI will recommend the corresponding Tar command. This is such a bad idea I don’t know where to start. Shell commands are a dangerous, but precise tool, somewhat like using a scalpel or a surgical tool. Dumbing it down so it can “guess what you want i…

What if it tells you to type `man tar`

Re: Building the Future of the Command Line

#46

Post by bhedgeoser »

oceanplexian wrote: post #38

> One of its modules attempts to translate natural language requests into the correct shell commands and syntax. For example, if you typed “compress Documents folder,” CLAI will recommend the corresponding Tar command. This is such a bad idea I don’t know where to start. Shell commands are a dangerous, but precise tool, somewhat like using a scalpel or a surgical tool. Dumbing it down so it can “guess what you want i…

I guess that's why shell programs use regexes and globs.

Re: Building the Future of the Command Line

#48

Post by none_to_remain »

Has anyone done anything around just ... mixing images in with the terminal output? Let's say I wanted to check if I had any old memes lying around my home directory, and have a quick look so I can decide to delete or not.

  ~$ls *{png,jpg}
  oldmeme.png 
  ~$imgcat oldmeme.png 
  /----------------\ 
  | oldmeme.png    | 
  | appears right  | 
  | here in the    | 
  | terminal       | 
  \----------------/ 
  ~$rm oldmeme.png
Terminfo man page shows some evidence of support for "bit_image" commands but none of the terminals in my terminfo files seem to have it. I have over 2000 terminfo files though, I like the idea that if I found some literal teletypewriter from 1973 and figured out some way to hook it up, I am probably prepared with the proper escape sequences.

Re: Building the Future of the Command Line

#49

Post by kretaceous »

none_to_remain wrote: post #48

Has anyone done anything around just ... mixing images in with the terminal output? Let's say I wanted to check if I had any old memes lying around my home directory, and have a quick look so I can decide to delete or not. ~$ls *{png,jpg} oldmeme.png ~$imgcat oldmeme.png /----------------\ | oldmeme.png | | appears right | | here in the | | terminal | \----------------/ ~$rm oldmeme.png Terminfo man page shows some e…

When I first installed viu[0], I did not think I'd be using it as much as I use it today.

PS: I use nnn[1] with the preview plugin which make use cases like yours very easy to solve.

0: https://github.com/atanunq/viu

1: https://github.com/jarun/nnn

Re: Building the Future of the Command Line

#50

Post by kybernetikos »

none_to_remain wrote: post #48

Has anyone done anything around just ... mixing images in with the terminal output? Let's say I wanted to check if I had any old memes lying around my home directory, and have a quick look so I can decide to delete or not. ~$ls *{png,jpg} oldmeme.png ~$imgcat oldmeme.png /----------------\ | oldmeme.png | | appears right | | here in the | | terminal | \----------------/ ~$rm oldmeme.png Terminfo man page shows some e…

I use wezterm which supports sixel, so I can do exactly what you show here. I use lsix and img2sixel in the terminal. Another fun thing you can try: curl v3.wttr.in/Texas.sxl
Post reply on HN