6 ms·

As someone who teaches these things occasionally to non-tech people I think the hard thing about CLI tools are the following: 1. The terminal when you first op

by atoav 3y ago

As someone who teaches these things occasionally to non-tech people I think the hard thing about CLI tools are the following: 1. The terminal when you first open it is intimidating to most and doesn't offer any help to figure out how to use it. If people think something is hard, they will have a harder time understanding it as well (same goes for thinking something will be boring, there have been studies on that) 2. Text editing in the terminal works different than literally anywhere else. You can't simply click and mark text, shortcuts are different, etc. 3. You have to get that text has to be exact, you have to know syntax rules with where to put spaces, how to work with quotes, escape strings and all that. That is just not easy. For those of us who already speak any given shell, this may be aomething we forget. But it is like learning a language and a way to think. Once you are fluent, it is easy. But it is worth it in my opinion, especially if you want to work with niche special tools or if you want reliable tools that will just work for decades.

9dev 3y ago
So do you think a terminal that works more along the way of thinking of non-technical people, or maybe similar to other text-based applications, could provide an entry point to non-technical power users? I have been thinking a lot about providing a shell-like experience as a quick way to make advanced functionality available in an app, without having to build fully fledged GUIs for them, but I’m not sure whether that would work. Clearly, discoverability and text input are the key issues, but I don’t know if alleviating those is sufficient to make the interface actually interesting and useful.
- deleted 3y ago
  [deleted]
- jonfw 3y ago
  VSCode's command palette is a great example of this- 1. fuzzy search through different options 2. Show lots of suggestions as soon as you focus in the text box 3. have a ? or other "learn more" option available I still think it leans very technical though, users would greatly prefer buttons. There's a good reason that powerpoint doesn't have one of these
- swozey 3y ago
  When I make terminal apps I make both a TUI and CLI option if the app is big enough to benefit from it. Here's an example: https://i.imgur.com/dxXwRzD.gifv https://i.imgur.com/dxXwRzD.gifv This allows the less familiar or technical staff to do things with the app and also allows for veterans or CLI afficiandos to alias/run what they want directly from the cli.
- atoav 3y ago
  I think using text to interface with computers is a genius idea and if it didn't exist someone would have ro invent it. But the way text interfaces on computers look nowadays are mostly shaped the way they are for historical reasons. It doesn't need much. First the text should be editable like other text on the OS, the cursor needs to be reactive ro mouse input. Second expected shortcuts should work, that means things like Ctrl+A to select all, Home to go to start of line, Ctrl+C for copy, Escape to cancel things, etc. I know there are reasons to everything and I am used to terminal shortcuts as well, but there is literally no reasons why we can't ensure they are the same there as everywhere else. Next thing would be the startup experience. If you start a terminal the first time, it should offer you some introduction. Sure, a seasoned user like me would be annoyed by that, but if you make it so it can be ignored by the likes of us or people that set the right environment variable, cool. Lastly, maybe it also a bit about the colors and fonts. I like bright on dark, but I can see how people who see this for the first time get flashbackanof every hacker scene they ever saw in any movie. And the subtext there always was: "You only understand this if you sacrifice all your social life". Imagine how a terminal would look like if it was made for kids and how that would make people judge their own ability to get this instead. I think a lot of the reason why terminals still look the way the do (apart from the fact it just works), is gatekeeping. Some nerds like that this is arcane, secret knowledge that looks as if it is hard to aquire. They don't like others to understand unless those others are also nerds.
  - 082349872349872 3y ago
    If you can make a friendly terminal, go for it! (if you can make an unfriendly but more consistent terminal, that'd also be a worthwhile improvement, just not for your target audience) If you're willing to lead the horse to water, we'd be able to see if it drinks.
    - 9dev 3y ago
      Seriously though, i would be able to spend development time on this. If anyone is considering too, send me a message.
bluetomcat 3y ago
The principal problem of any sufficiently advanced CLI tool is the combinatorial explosion of options. With more than a dozen options, you start having special cases like "it does foo when the bar option is used, baz otherwise". In a GUI, you generally express exclusivity or inclusivity with the use of the correct UI elements – a checkbox can become disabled when something else is selected.
- _kb 3y ago
  That would be an interesting interaction to explore with a colourised terminal. Essential have contextual colouring on input so that mutually exclusive params are either shaded in the case of clear precedence or highlighted for conflict. It's not an area I've played with but wonder if that could be hacked into exisiting autocomplete mechanisms?
  - oblio 3y ago
    fish shell.
    - _kb 3y ago
      I was hinting/hoping at something beyond what fish does. Rather than just structural colouring (params are colour a, valid paths colour b etc) the input is recoloured as you type in response to validity for the specific tool you're about to invoke.
- JeffSnazz 3y ago
  With all these command-line parser libs, I'm surprised there aren't more libraries that automatically generate a graphical interface for them. Would be super useful for e.g. ffmpeg, cc, curl, etc. Especially for people unfamiliar with the program....
  - blackbear_ 3y ago
    There is for Python: https://github.com/chriskiehl/Gooey https://github.com/chriskiehl/Gooey
roenxi 3y ago
(1) is an important point, but I think it doesn't go far enough. The terminal offers no help at all to a casual user (the funniest case of this is watching a new user trying to quit vim [0]). There are a specific set of skills required to learn how to use the terminal - a combination of knowing when and how to read man pages, when to look up Stack Overflow, when to look up YouTube videos, and where to hang out to learn about more esoteric commands exist like `parallel`. Without those skills - and there is no recommended path on how to get them - the terminal is unusable. It isn't a case of people thinking it is hard, it is actually logically impossible to learn how to learn terminal commands without getting lucky at the start. Software has two phases - a learning phase and a using phase. A lot of great software ideas died quietly because there wasn't a sanctioned route to scale the learning curve. [0] Or this classic: https://cs.wellesley.edu/~cs249/Resources/ed_is_the_standard_text_editor.html https://cs.wellesley.edu/~cs249/Resources/ed_is_the_standard...
- Phiwise_ 3y ago
  To add on to (1), expeeienced hackers trying to educate new users really should first immerse themselves into descriptions of the "bad old days" of utility programming to help get back into the mindset of the novice they're trying to relate to. Your ed link is good, and I like the "Power Tools for Power Fools"/"Teeminal Insanity" chapter of The Unix-Haters Handbook for something slightly more modern: https://simson.net/ref/ugh.pdf#page=185 https://simson.net/ref/ugh.pdf#page=185 Just like no one really uses ed anymore, the C shell is pretty much dead and many userspace programs have had their edges rounded over the years, but the experience of trying to imagine working around their foibles gives the perspective necessary to helpfully advise someone trying to learn an acceptable shell today (except that they'll have more use for their effort at some point) because they're pretty much the same kind of transition. Compare these highlights to that ed page: >Pipes are not the be-all and end-all of program communication. Our favor-ite Unix-loving book had this to say about the Macintosh, which doesn’t have pipes: "The Macintosh model, on the other hand, is the exact opposite. The system doesn’t deal with character streams. Data files are extremely high level, usually assuming that they are specific to an application. When was the last time you piped the output of one program to another on a Mac? (Good luck even finding the pipe symbol.) Pro-grams are monolithic, the better to completely understand what you are doing. You don’t take MacFoo and MacBar and hook them together." Yeah, those poor Mac users. They’ve got it so rough. Because they can’t pipe streams of bytes around how are they ever going to paste artwork from their drawing program into their latest memo and have text flow around it? How are they going to transfer a spreadsheet into their memo? And how could such users expect changes to be tracked automatically? They cer-tainly shouldn’t expect to be able to electronically mail this patched-together memo across the country and have it seamlessly read and edited at the other end, and then returned to them unscathed. We can’t imagine how they’ve been transparently using all these programs together for the last 10 years and having them all work, all without pipes. >This morning I read an article in the Journal of Human-Computer Interaction, “Expertise in a Computer Operating System,” by Stephanie M. Doane and two others. Guess which operating system she studied? Doane studied the knowledge and performance of Unix novices, intermediates, and expert users. Here are few quotes: “Only experts could successfully produce composite commands that required use of the distinctive features of Unix (e.g. pipes and other redirection symbols).” In other words, every feature that is new in Unix (as opposed to being copied, albeit in a defective or degenerate form from another operat-ing system) is so arcane that it can be used only after years of arcane study and practice. “This finding is somewhat surprising, inasmuch as these are fundamental design features of Unix, and these features are taught in elementary classes.” In both cases, we have someone moving from a relatively monolithic, high-level, restricted, commercialized system that focuses on uniformity, error-bar tolerance, and DWIM/intuitiveness of the intended or common use-case over giving every capability equal billing to one that focuses on completeness, atomicity, and implementation simplicity/efficiency. Learning this transition has two phases because the best way to keep going with the learner's current knowledge has two phases: Before making the transition they probably learned the old system through self-tutoring and exploration; the stakes were low enough and the environment painstakingly organized to be similar enough that a little curiosity and a little induction from past experience explained basically every level of the user-visible stack, and the slab of composed foundation functions that made the first-blush system run were either walled off fully or guarded to wave away novices. Pre grokking the new software, though, the user lacks the idioms that make it possible to write a more complete computing system out of less code, and so don't know when to apply what even if they've read up on most of the pieces they need already. It's like a transition from an upper-class aerospace engineer or hedge fund manager exploring Animal Kingdom Park to making a trek through the indian jungle. Even if you're carrying a reference tome on the region there are intangibles you're just missing, so you're far more likely to get lost and confused or hurt yourself if you don't walk right in the footsteps of someone expeeienced for a good long while. It's similar with the terminal: When you're successful, things are clearer and simpler than a jumbled heavyweight gui, but when you make the "mistakes" that come along with not almost entirely knowing what you're doing it can be unhelpful, mystifying, and rarely dangerous, because the experienced users happen to be the most-engaged target market. Not everyone has Apple money, after all. The phase change back to effective exploration, and actual use over learning through apeing, only comes after they've got both most of the terrain and most of the problem-solving strategies in their head all at once to hit a self-sustaining critical mass. Something akin to the Khan(academy) flipped method is what I think is most important to remember when teaching: most experienced users think in terms of learning new skills through integrating new components, while beginners tend to know less about the implications of recombining the utilities they're already aware of in the less common and simple ways than show up as line snippets in crash courses. New users can read a man page as well as you can recite it by heart, but what they really need tutoring in is how to know they're reading the right part of the right page and what your experience says to do with it. Just getting that all off my chest as someone who didn't have anyone to teach me and used to be spectacularly bad at teaching others, so someone might learn from my mistakes.
swozey 3y ago
1. You teach so your experience is probably very different from us SWE/SREs who only work with other technical staff for the most part. 2. You can add cursor and mouse control to your .nanorc. I'm not sure if bash, etc have that. With that said, I have cursor enabled in my .nanorc along with a bunch of other stuff. The cursor thing.. I'm kind of confused on how you use it, but I rarely use it. It's (to me) weird. I think I just havent used it enough to really know its capabilites. I think as a teacher it'd be super helpful to you to have a base set of dotfiles that your students just git clone when they start the class. Or even better, have them write their own and just provide them the settings you want them to enable. When I bring new SREs on board, without the base dotfiles for them to grab on day 1 it takes practically a week for someone to get setup and ready to work. Have each of them commit their dotfiles to their own repos, probably forked from yours. That will get them familiar with github. Then try to get them to actually build out a github portfolio. I spent 6 months interviewing for a few positions last year and I was really surprised how few people had githubs with anything on them. It's not my main criteria but it's nice when someone has put effort into their gh/gitlab/etc profile and projects. Also please teach them about filesystems. Most of the younger people (20s) I interviewed knew very little linux/containerization/filesystems.. I think the filesystem thing is from them growing up with MacOS and iPhones. They don't need to dig into anything beyond their "folders" if even that. 3. Absolutely one of my CLI annoyances here. I wrote another comment explaining why it frustrates me. Related to your last sentence- I'd say 99% of the CLI/TUI apps I write are things that give you an easy front end (TUI and simple commands/flags) to perform backend systems tasks. So I have a ton of them as an SRE. The main reason I like to put things in a TUI and not just CLI flags is that ANYONE can hop in and use it because the options are all displayed to you front and center. You just use arrows or numbers to navigate. I do TUI *AND* command line flags because some people want to do it quick and fast, or make aliases, etc for what they're doing. THen there's the TUI which opens if you don't run a flag, the TUI is so, so helpful to people new to the apps. This lets me democratize the various apps I've created and let anyone who isn't me use them. It's great. Here's one example of my TUI+CLI apps. This is super old it's much prettier now. https://i.imgur.com/dxXwRzD.gifv https://i.imgur.com/dxXwRzD.gifv
- cfiggers 3y ago
  > I do TUI AND command line flags because some people want to do it quick and fast, or make aliases, etc for what they're doing. THen there's the TUI which opens if you don't run a flag, the TUI is so, so helpful to people new to the apps. YES, this is the way to go! I've written a couple of internal tools that work this way and it's the best of both worlds IMO.
nkrisc 3y ago
The biggest issue I’ve see , particularly regarding your first point, is simple discoverability of capabilities. It is very difficult, at least initially, to even begin to discover what’s possible in a terminal environment. There are so many important things that a new user simply needs to be taught, or they will likely never discover basic functionality - such as how to even open, read, and navigate the manual. The UX barrier to entry is very high without hand-holding or extensive online searching and a strong willingness to persevere in the face of adversity. GUI applications (generally) solve the initial discoverability barrier by simply showing you what’s possible. I remember being a kid looking at DOS and wondering “what do I even do?” It was essentially a blank screen with very little indication of how to proceed. My dad had sticky notes on the monitor with the commands to enter to run games. I never really looked at a command line again after I started using the Windows desktop until I started really learning programming after college, and it was just as daunting at first.
- 082349872349872 3y ago
  > important things a new user simply needs to be taught, or they will likely never discover basic functionality In the ancient times, we'd say "RTFM" to people who attempted to "discover" functionality instead of Ring the Fing M.
  - dullcrisp 3y ago
    Well maybe that was the problem.
    - 082349872349872 3y ago
      Imagine if people had to discover algebra instead of learning it. We'd probably still be subject to the whims of kings and priests. (to what extent have we made progress in software by standing on each others' shoulders instead of each others' toes, and to what extent have we been fortunate that the EEs have been standing on each others' shoulders this short century?) Note that I'm not anti-discoverability in general — it's just the ticket for GUIs. I just happen to believe that attempting to make CLIs discoverable would nerf their greatest power: that single-character changes can have drastic effects on behaviour. We have high display bandwidths, even in our pockets, so why not have GUIs for infrequently used software and CLIs for power used software?
datastoat 3y ago
It'd be fun (and a bit scary) to use an LLM as a shell replacement. We'd give it the history of our commands as per the recent post [0], as well as their outputs, and it would turn natural-language commands into proper bash. The xkcd comic [1] would be solved instantly. "Tar these files, please." "Delete all the temporary files but please please please don't delete anything else." I'm sure people have implemented this, but my searching isn't good enough to find it. [0] https://news.ycombinator.com/item?id=38965003 https://news.ycombinator.com/item?id=38965003 [1] https://xkcd.com/1168/ https://xkcd.com/1168/
- floren 3y ago
  I have briefly told ChatGPT 3.5 about the syntax of a CLI tool I wrote, then asked it to perform a few operations. It did a surprisingly good job, even when I said "and format the result as JSON with fields named Command and Description where the latter explains what the command does". If I was to actually use this in a real system, I'd definitely build a restricted shell to execute in, and probably run it inside a Docker container with just the essential files mapped in, because I don't trust an LLM not to describe what it's doing as "updating timestamps" or whatever but actually the command is "rm -rf ~"
mgdlbp 3y ago
btw xterm has a hack for editors without mouse support – turn clicks into the right number of movement key presses, uxterm -xrm '*VT100.translations: #override !<Btn1Down>: vi-button() readline-button()'
yjftsjthsd-h 3y ago
> 2. Text editing in the terminal works different than literally anywhere else. You can't simply click and mark text, shortcuts are different, etc. One of the interesting things Plan 9 did differently is that its terminal is rather more like a standard graphical text editor that happens to have the ability to execute a line. As someone used to unix terminals this was super jarring, but I can see where it would be nice.
- pmontra 3y ago
  I never gave Plan 9 a try so I might have misunderstood what you say but Emacs shell mode works in a similar way.
deleted 3y ago
[deleted]
082349872349872 3y ago
> 3. You have to get that text has to be exact The obvious solution here is that people who don't like precision can pay people who do to wrangle CLIs on their behalf.
- xtreme 3y ago
  For now. Soon they will pay an LLM to translate their imprecise requests to precise commands.

by atoav 3y ago

9dev 3y ago

So do you think a terminal that works more along the way of thinking of non-technical people, or maybe similar to other text-based applications, could provide an entry point to non-technical power users? I have been thinking a lot about providing a shell-like experience as a quick way to make advanced functionality available in an app, without having to build fully fledged GUIs for them, but I’m not sure whether that would work. Clearly, discoverability and text input are the key issues, but I don’t know if alleviating those is sufficient to make the interface actually interesting and useful.

deleted 3y ago
[deleted]
jonfw 3y ago
VSCode's command palette is a great example of this- 1. fuzzy search through different options 2. Show lots of suggestions as soon as you focus in the text box 3. have a ? or other "learn more" option available I still think it leans very technical though, users would greatly prefer buttons. There's a good reason that powerpoint doesn't have one of these
swozey 3y ago
When I make terminal apps I make both a TUI and CLI option if the app is big enough to benefit from it. Here's an example: https://i.imgur.com/dxXwRzD.gifv https://i.imgur.com/dxXwRzD.gifv This allows the less familiar or technical staff to do things with the app and also allows for veterans or CLI afficiandos to alias/run what they want directly from the cli.
atoav 3y ago
I think using text to interface with computers is a genius idea and if it didn't exist someone would have ro invent it. But the way text interfaces on computers look nowadays are mostly shaped the way they are for historical reasons. It doesn't need much. First the text should be editable like other text on the OS, the cursor needs to be reactive ro mouse input. Second expected shortcuts should work, that means things like Ctrl+A to select all, Home to go to start of line, Ctrl+C for copy, Escape to cancel things, etc. I know there are reasons to everything and I am used to terminal shortcuts as well, but there is literally no reasons why we can't ensure they are the same there as everywhere else. Next thing would be the startup experience. If you start a terminal the first time, it should offer you some introduction. Sure, a seasoned user like me would be annoyed by that, but if you make it so it can be ignored by the likes of us or people that set the right environment variable, cool. Lastly, maybe it also a bit about the colors and fonts. I like bright on dark, but I can see how people who see this for the first time get flashbackanof every hacker scene they ever saw in any movie. And the subtext there always was: "You only understand this if you sacrifice all your social life". Imagine how a terminal would look like if it was made for kids and how that would make people judge their own ability to get this instead. I think a lot of the reason why terminals still look the way the do (apart from the fact it just works), is gatekeeping. Some nerds like that this is arcane, secret knowledge that looks as if it is hard to aquire. They don't like others to understand unless those others are also nerds.
- 082349872349872 3y ago
  If you can make a friendly terminal, go for it! (if you can make an unfriendly but more consistent terminal, that'd also be a worthwhile improvement, just not for your target audience) If you're willing to lead the horse to water, we'd be able to see if it drinks.
  - 9dev 3y ago
    Seriously though, i would be able to spend development time on this. If anyone is considering too, send me a message.

bluetomcat 3y ago

The principal problem of any sufficiently advanced CLI tool is the combinatorial explosion of options. With more than a dozen options, you start having special cases like "it does foo when the bar option is used, baz otherwise". In a GUI, you generally express exclusivity or inclusivity with the use of the correct UI elements – a checkbox can become disabled when something else is selected.

_kb 3y ago
That would be an interesting interaction to explore with a colourised terminal. Essential have contextual colouring on input so that mutually exclusive params are either shaded in the case of clear precedence or highlighted for conflict. It's not an area I've played with but wonder if that could be hacked into exisiting autocomplete mechanisms?
- oblio 3y ago
  fish shell.
  - _kb 3y ago
    I was hinting/hoping at something beyond what fish does. Rather than just structural colouring (params are colour a, valid paths colour b etc) the input is recoloured as you type in response to validity for the specific tool you're about to invoke.
JeffSnazz 3y ago
With all these command-line parser libs, I'm surprised there aren't more libraries that automatically generate a graphical interface for them. Would be super useful for e.g. ffmpeg, cc, curl, etc. Especially for people unfamiliar with the program....
- blackbear_ 3y ago
  There is for Python: https://github.com/chriskiehl/Gooey https://github.com/chriskiehl/Gooey

roenxi 3y ago

(1) is an important point, but I think it doesn't go far enough. The terminal offers no help at all to a casual user (the funniest case of this is watching a new user trying to quit vim [0]). There are a specific set of skills required to learn how to use the terminal - a combination of knowing when and how to read man pages, when to look up Stack Overflow, when to look up YouTube videos, and where to hang out to learn about more esoteric commands exist like `parallel`. Without those skills - and there is no recommended path on how to get them - the terminal is unusable. It isn't a case of people thinking it is hard, it is actually logically impossible to learn how to learn terminal commands without getting lucky at the start. Software has two phases - a learning phase and a using phase. A lot of great software ideas died quietly because there wasn't a sanctioned route to scale the learning curve. [0] Or this classic: https://cs.wellesley.edu/~cs249/Resources/ed_is_the_standard_text_editor.html https://cs.wellesley.edu/~cs249/Resources/ed_is_the_standard...

Phiwise_ 3y ago
To add on to (1), expeeienced hackers trying to educate new users really should first immerse themselves into descriptions of the "bad old days" of utility programming to help get back into the mindset of the novice they're trying to relate to. Your ed link is good, and I like the "Power Tools for Power Fools"/"Teeminal Insanity" chapter of The Unix-Haters Handbook for something slightly more modern: https://simson.net/ref/ugh.pdf#page=185 https://simson.net/ref/ugh.pdf#page=185 Just like no one really uses ed anymore, the C shell is pretty much dead and many userspace programs have had their edges rounded over the years, but the experience of trying to imagine working around their foibles gives the perspective necessary to helpfully advise someone trying to learn an acceptable shell today (except that they'll have more use for their effort at some point) because they're pretty much the same kind of transition. Compare these highlights to that ed page: >Pipes are not the be-all and end-all of program communication. Our favor-ite Unix-loving book had this to say about the Macintosh, which doesn’t have pipes: "The Macintosh model, on the other hand, is the exact opposite. The system doesn’t deal with character streams. Data files are extremely high level, usually assuming that they are specific to an application. When was the last time you piped the output of one program to another on a Mac? (Good luck even finding the pipe symbol.) Pro-grams are monolithic, the better to completely understand what you are doing. You don’t take MacFoo and MacBar and hook them together." Yeah, those poor Mac users. They’ve got it so rough. Because they can’t pipe streams of bytes around how are they ever going to paste artwork from their drawing program into their latest memo and have text flow around it? How are they going to transfer a spreadsheet into their memo? And how could such users expect changes to be tracked automatically? They cer-tainly shouldn’t expect to be able to electronically mail this patched-together memo across the country and have it seamlessly read and edited at the other end, and then returned to them unscathed. We can’t imagine how they’ve been transparently using all these programs together for the last 10 years and having them all work, all without pipes. >This morning I read an article in the Journal of Human-Computer Interaction, “Expertise in a Computer Operating System,” by Stephanie M. Doane and two others. Guess which operating system she studied? Doane studied the knowledge and performance of Unix novices, intermediates, and expert users. Here are few quotes: “Only experts could successfully produce composite commands that required use of the distinctive features of Unix (e.g. pipes and other redirection symbols).” In other words, every feature that is new in Unix (as opposed to being copied, albeit in a defective or degenerate form from another operat-ing system) is so arcane that it can be used only after years of arcane study and practice. “This finding is somewhat surprising, inasmuch as these are fundamental design features of Unix, and these features are taught in elementary classes.” In both cases, we have someone moving from a relatively monolithic, high-level, restricted, commercialized system that focuses on uniformity, error-bar tolerance, and DWIM/intuitiveness of the intended or common use-case over giving every capability equal billing to one that focuses on completeness, atomicity, and implementation simplicity/efficiency. Learning this transition has two phases because the best way to keep going with the learner's current knowledge has two phases: Before making the transition they probably learned the old system through self-tutoring and exploration; the stakes were low enough and the environment painstakingly organized to be similar enough that a little curiosity and a little induction from past experience explained basically every level of the user-visible stack, and the slab of composed foundation functions that made the first-blush system run were either walled off fully or guarded to wave away novices. Pre grokking the new software, though, the user lacks the idioms that make it possible to write a more complete computing system out of less code, and so don't know when to apply what even if they've read up on most of the pieces they need already. It's like a transition from an upper-class aerospace engineer or hedge fund manager exploring Animal Kingdom Park to making a trek through the indian jungle. Even if you're carrying a reference tome on the region there are intangibles you're just missing, so you're far more likely to get lost and confused or hurt yourself if you don't walk right in the footsteps of someone expeeienced for a good long while. It's similar with the terminal: When you're successful, things are clearer and simpler than a jumbled heavyweight gui, but when you make the "mistakes" that come along with not almost entirely knowing what you're doing it can be unhelpful, mystifying, and rarely dangerous, because the experienced users happen to be the most-engaged target market. Not everyone has Apple money, after all. The phase change back to effective exploration, and actual use over learning through apeing, only comes after they've got both most of the terrain and most of the problem-solving strategies in their head all at once to hit a self-sustaining critical mass. Something akin to the Khan(academy) flipped method is what I think is most important to remember when teaching: most experienced users think in terms of learning new skills through integrating new components, while beginners tend to know less about the implications of recombining the utilities they're already aware of in the less common and simple ways than show up as line snippets in crash courses. New users can read a man page as well as you can recite it by heart, but what they really need tutoring in is how to know they're reading the right part of the right page and what your experience says to do with it. Just getting that all off my chest as someone who didn't have anyone to teach me and used to be spectacularly bad at teaching others, so someone might learn from my mistakes.

swozey 3y ago

1. You teach so your experience is probably very different from us SWE/SREs who only work with other technical staff for the most part. 2. You can add cursor and mouse control to your .nanorc. I'm not sure if bash, etc have that. With that said, I have cursor enabled in my .nanorc along with a bunch of other stuff. The cursor thing.. I'm kind of confused on how you use it, but I rarely use it. It's (to me) weird. I think I just havent used it enough to really know its capabilites. I think as a teacher it'd be super helpful to you to have a base set of dotfiles that your students just git clone when they start the class. Or even better, have them write their own and just provide them the settings you want them to enable. When I bring new SREs on board, without the base dotfiles for them to grab on day 1 it takes practically a week for someone to get setup and ready to work. Have each of them commit their dotfiles to their own repos, probably forked from yours. That will get them familiar with github. Then try to get them to actually build out a github portfolio. I spent 6 months interviewing for a few positions last year and I was really surprised how few people had githubs with anything on them. It's not my main criteria but it's nice when someone has put effort into their gh/gitlab/etc profile and projects. Also please teach them about filesystems. Most of the younger people (20s) I interviewed knew very little linux/containerization/filesystems.. I think the filesystem thing is from them growing up with MacOS and iPhones. They don't need to dig into anything beyond their "folders" if even that. 3. Absolutely one of my CLI annoyances here. I wrote another comment explaining why it frustrates me. Related to your last sentence- I'd say 99% of the CLI/TUI apps I write are things that give you an easy front end (TUI and simple commands/flags) to perform backend systems tasks. So I have a ton of them as an SRE. The main reason I like to put things in a TUI and not just CLI flags is that ANYONE can hop in and use it because the options are all displayed to you front and center. You just use arrows or numbers to navigate. I do TUI *AND* command line flags because some people want to do it quick and fast, or make aliases, etc for what they're doing. THen there's the TUI which opens if you don't run a flag, the TUI is so, so helpful to people new to the apps. This lets me democratize the various apps I've created and let anyone who isn't me use them. It's great. Here's one example of my TUI+CLI apps. This is super old it's much prettier now. https://i.imgur.com/dxXwRzD.gifv https://i.imgur.com/dxXwRzD.gifv

cfiggers 3y ago
> I do TUI AND command line flags because some people want to do it quick and fast, or make aliases, etc for what they're doing. THen there's the TUI which opens if you don't run a flag, the TUI is so, so helpful to people new to the apps. YES, this is the way to go! I've written a couple of internal tools that work this way and it's the best of both worlds IMO.

nkrisc 3y ago

The biggest issue I’ve see , particularly regarding your first point, is simple discoverability of capabilities. It is very difficult, at least initially, to even begin to discover what’s possible in a terminal environment. There are so many important things that a new user simply needs to be taught, or they will likely never discover basic functionality - such as how to even open, read, and navigate the manual. The UX barrier to entry is very high without hand-holding or extensive online searching and a strong willingness to persevere in the face of adversity. GUI applications (generally) solve the initial discoverability barrier by simply showing you what’s possible. I remember being a kid looking at DOS and wondering “what do I even do?” It was essentially a blank screen with very little indication of how to proceed. My dad had sticky notes on the monitor with the commands to enter to run games. I never really looked at a command line again after I started using the Windows desktop until I started really learning programming after college, and it was just as daunting at first.

082349872349872 3y ago
> important things a new user simply needs to be taught, or they will likely never discover basic functionality In the ancient times, we'd say "RTFM" to people who attempted to "discover" functionality instead of Ring the Fing M.
- dullcrisp 3y ago
  Well maybe that was the problem.
  - 082349872349872 3y ago
    Imagine if people had to discover algebra instead of learning it. We'd probably still be subject to the whims of kings and priests. (to what extent have we made progress in software by standing on each others' shoulders instead of each others' toes, and to what extent have we been fortunate that the EEs have been standing on each others' shoulders this short century?) Note that I'm not anti-discoverability in general — it's just the ticket for GUIs. I just happen to believe that attempting to make CLIs discoverable would nerf their greatest power: that single-character changes can have drastic effects on behaviour. We have high display bandwidths, even in our pockets, so why not have GUIs for infrequently used software and CLIs for power used software?

datastoat 3y ago

It'd be fun (and a bit scary) to use an LLM as a shell replacement. We'd give it the history of our commands as per the recent post [0], as well as their outputs, and it would turn natural-language commands into proper bash. The xkcd comic [1] would be solved instantly. "Tar these files, please." "Delete all the temporary files but please please please don't delete anything else." I'm sure people have implemented this, but my searching isn't good enough to find it. [0] https://news.ycombinator.com/item?id=38965003 https://news.ycombinator.com/item?id=38965003 [1] https://xkcd.com/1168/ https://xkcd.com/1168/

floren 3y ago
I have briefly told ChatGPT 3.5 about the syntax of a CLI tool I wrote, then asked it to perform a few operations. It did a surprisingly good job, even when I said "and format the result as JSON with fields named Command and Description where the latter explains what the command does". If I was to actually use this in a real system, I'd definitely build a restricted shell to execute in, and probably run it inside a Docker container with just the essential files mapped in, because I don't trust an LLM not to describe what it's doing as "updating timestamps" or whatever but actually the command is "rm -rf ~"

mgdlbp 3y ago

btw xterm has a hack for editors without mouse support – turn clicks into the right number of movement key presses, uxterm -xrm '*VT100.translations: #override !<Btn1Down>: vi-button() readline-button()'

yjftsjthsd-h 3y ago

> 2. Text editing in the terminal works different than literally anywhere else. You can't simply click and mark text, shortcuts are different, etc. One of the interesting things Plan 9 did differently is that its terminal is rather more like a standard graphical text editor that happens to have the ability to execute a line. As someone used to unix terminals this was super jarring, but I can see where it would be nice.

pmontra 3y ago
I never gave Plan 9 a try so I might have misunderstood what you say but Emacs shell mode works in a similar way.

deleted 3y ago

[deleted]

082349872349872 3y ago

> 3. You have to get that text has to be exact The obvious solution here is that people who don't like precision can pay people who do to wrangle CLIs on their behalf.

xtreme 3y ago
For now. Soon they will pay an LLM to translate their imprecise requests to precise commands.