I know that GUI does not cover most of functionalities, for good reasons - being specialized to task (like files app), it provides more fine-grained experience.

Yet, I find that there are common commands which is terminal-only, or not faithfully implemented. for instance,

  • Commands like apt update/apt upgrade might be needed, as GUI may not allow enough interactions with it.
  • I heard some immutable distros require running commands for rollbacks.

These could cause some annoyance for those who want to avoid terminal unless necessary (including me). Hence, I bet there are terminal emulators which restricts what commands you could run, and above all, present them as buttons. This will make you recall the commonly used commands, and run them accordingly. Is there projects similar to what I describe? Thanks!

  • @pivot_root@lemmy.world
    link
    fedilink
    304 months ago

    I understand the desire to want to avoid the command line, but you’re severely restricting your ability to troubleshoot by doing so. Every operating system has a terminal and command line, and there’s going to be cases where you’ll want to drop into a shell to do something that has no GUI equivalent.

      • @Telorand@reddthat.com
        link
        fedilink
        24 months ago

        You should see if there’s a Windows equivalent (since it has the most market share by a country mile). If it does, use that for ideas, and improve upon it. If not, it may not be feasible or reasonable based on your goals.

    • @WbrJr@lemmy.ml
      link
      fedilink
      34 months ago

      I dont think you should habe to learn to usw the terminal in order to debug your operating system. If i would switch my mom to Linux, i dont want her to have to use the terminal. So making life easier for those people would grealty improve the appeal of Linux to tech noobs. By arguing we need the terminal for Linux, we gatekeep people from trying and using Linux, if they are afraid of technology

  • @refalo@programming.dev
    link
    fedilink
    15
    edit-2
    4 months ago

    I know that GUI does not cover most of functionalities

    specialized to task

    Yet, I find that there are common commands

    present them as buttons

    Congratulations you just reinvented the GUI while trying to get away from it at the same time.

    Perhaps something a little more “in-between” the two might be a GUI that allows running arbitrary programs… something smarter than a launcher but more generic than a purpose-built function-limited interface… if such a thing can even exist.

    • @Octorine@midwest.social
      link
      fedilink
      English
      14 months ago

      There are already libraries like clap that allow the developer to specify all their arguments including short and long variants and description strings. I think some of them will automatically generate --help based on the specified options. I could imagine a library that takes the same specifications and makes an interactive menu or a tui form out of them. It’s an interesting idea.

      • @refalo@programming.dev
        link
        fedilink
        3
        edit-2
        4 months ago

        I don’t think there is one yet… it would need some kind of way to understand the possible options and parameters for any given CLI program, and without a standardized interface for that, error-prone scraping of --help or just hard-coding popular options is probably the best you could do. Hopefully it wouldn’t end up looking something like the Scratch programming IDE though.

        This reminds of jc which is kindof the opposite where it scrapes the output of common commands to present a more unified (JSON) syntax for other programs to consume and automate better.

  • @Nibodhika@lemmy.world
    link
    fedilink
    134 months ago

    The thing is that there is no middle ground, the terminal you described would either have the problems of a GUI (limited interactivity) or the problems of a CLI (unintuitive).

    If you do a button to do things you’ve removed option to do different things, if you ask them for text you’ve removed the intuitivity of a button. If you present less options you might not cover all cases, if you present more options it’s a regular terminal.

    It seems that the issue you have is that you need a way to quickly redo commands you’ve done before and you need a good way to know what options you have. I have 2 CLI solutions for you.

    1. If you press Ctrl+R and start typing a command it will auto-complete to the latest command you ran that matches

    2. If you install zsh and grml-zsh-config and switch to zsh you will have a very powerful auto-complete that will allow you to press tab to auto-complete most parameters of most common operations.

    • @someacnt_@lemmy.worldOP
      link
      fedilink
      34 months ago

      Yeah, I understand that this is difficult. But I am suggesting this considering lack of polish (ime) in commands.

      On the recalling, remembering entire commands is not the problematic one for me. Rather, I want a quick way to go with which apps do which.

      Also, terminals (that is, how most of the commands run) honestly do not look and feel good. I do think polished TUI could be a good solution, but they are not widespread.

  • brianorca
    link
    fedilink
    104 months ago

    This actually exists, but for a different operating system. The AS400 (aka iSeries) had a command line where programs had a standard way to specify parameters, so that pressing a prompt key (F4) would allow you to build the proper command line by filling a form. I do miss that, pity it doesn’t exist for Linux.

  • @gomp@lemmy.ml
    link
    fedilink
    7
    edit-2
    4 months ago

    I bet that doesn’t exist: nobody would put work in a program that lets just restricts what you can do with zero usability advantages (ok someone might)

    If you fear you might run unsafe commands just save whatever you are comfortable running in scripts and restrict yourself to run those instead of manually typing commands you don’t fully remember/understand.

    BTW: topgrade will detect what needs updating in your system (your distro’s package manager, flatpak, python stuff, … whatever) and update all the things

    BTW: “terminal emulator” is the program that shows you text in a window, the program that runs inside it and validates/interprets your commands is a “shell” (the one you are using is most probably bash)

    • @someacnt_@lemmy.worldOP
      link
      fedilink
      -24 months ago

      Calling it “terminal emulator” was a poor word usage on my end, yeah. I do not fear myself running command line though. I just want to avoid CLI.

  • palordrolap
    link
    fedilink
    74 months ago

    Coming back to this with thoughts. What you’re describing sounds a lot like a menu tree.

    “Press 1 to do this, 2 to do that, 3 to go to submenu A, 4 for B,” etc. 1

    “You have pressed 1. Do you want to turn on option ABC? [Y / n]” Y

    “Do you want option QWERTY47? [Y/n]” N

    “Are you sure you want to run notthebees --abc --no-qwerty47? [Y/n]” N

    “Aborted.”

    It sounds like a standards problem waiting to happen because no two menus will be alike, but hey, things like this can and do exist, and setting one up isn’t that hard, only time consuming.

    • @Telorand@reddthat.com
      link
      fedilink
      44 months ago

      This was my thought exactly. And I also had the same assessment that having various arguments be context aware would be challenging, since some have sub-arguments of their own (with further sub-arguments of their own, etc.) but can sometimes be strung together all on the same line. How do you determine if someone wants an ascendant argument or a descendant argument when you’re three layers deep into the tree?

      You would have to make opinionated decisions, which was the whole reason to avoid scripts in the first place. Seems like it would be better to just make executable scripts (which is what Fedora Atomics basically do with the just command) or gamify learning how to work in the terminal.

    • @Static_Rocket@lemmy.world
      link
      fedilink
      English
      34 months ago

      Something like this can kind of be achieved programmatically by unraveling bash completion arguments and loosely parsing terminal help strings.

      They aren’t all formatted uniformly though, so you’ll need to come up with a filtering mechanism to prevent returning garbage. You’ll also always be a little out of date…

  • @mkwt@lemmy.world
    link
    fedilink
    54 months ago

    For example, synaptic is a long running front end for apt that has the buttons for update and upgrade.

  • @atzanteol@sh.itjust.works
    link
    fedilink
    English
    44 months ago

    Just create GUI application for the things you want. There’s already lots of them.

    Otherwise there’s always “–help”.

    • @someacnt_@lemmy.worldOP
      link
      fedilink
      04 months ago

      I mean, there are already tons of applications that lets you e.g. update, like apt update/upgrade does.

      One issue with it is that it fails time to time, and error messages the GUI usually conveys are subpar. That’s why I think you cannot avoid terminals. I just want some middle ground for that.

      Also, ik this is nitpicking but… while apt is good on this front… what about the CLIs whose --help gives hundreds of lines?

      • @atzanteol@sh.itjust.works
        link
        fedilink
        English
        44 months ago

        I mean, there are already tons of applications that lets you e.g. update, like apt update/upgrade does.

        Bingo.

        while apt is good on this front… what about the CLIs whose --help gives hundreds of lines?

        Read them. There’s a reason some programs have many options. Avoiding the CLI isn’t the solution.

        • @someacnt_@lemmy.worldOP
          link
          fedilink
          24 months ago

          The apps just fail and crash randomly, any linux users cannot entirely rely on them. Well, I guess linux is destined for 2% of desktop users, who can use terminal on a daily basis, and current rise is just a fluke.

          • @atzanteol@sh.itjust.works
            link
            fedilink
            English
            0
            edit-2
            4 months ago

            Yes, that’s fine. If you didn’t like Linux you’re welcome to not use it.

            You see the console as a flaw. Some of us see it as an advantage.

          • @Telorand@reddthat.com
            link
            fedilink
            04 months ago

            Well, I guess linux is destined for 2% of desktop users, who can use terminal on a daily basis, and current rise is just a fluke.

            Dunno what you’re talking about. Most people I’ve seen who have made the switch just go learn how to use the terminal. You’ll have to eventually, since many people have use cases that fall outside the sane defaults of whatever distro you chose, and there’s tons of videos, online communities, and written tutorials to help.

            The rest know somebody who can help or just want a system that can do whatever defaults it’s been set up to do out of the box (e.g. open pictures, use a web browser, play Steam games, etc.).

  • @AbouBenAdhem@lemmy.world
    link
    fedilink
    English
    4
    edit-2
    4 months ago

    Rather than creating a custom terminal app, could you create a user that only had permission to run the restricted commands, with a profile script that gets run at login and offers a menu of common tasks?

  • @tunetardis@lemmy.ca
    link
    fedilink
    English
    44 months ago

    This reminds me of something from my ancient past. Back in the early-ish days of Apple, there was a development system called MPW (Macintosh Programmer’s Workshop) which included its own little kludgy shell.

    The weird thing about it though was while you could enter commands on the command line like in any shell, you could prefix them with the word commando (presumably a portmanteau of “command” and “window”) and this window would pop up showing various buttons, checkboxes, etc. correponding to command line options. When you ok’d the window, it would generate the command line for you.

    I’m rather hazy about how all this worked, but I think there was some sort of template language to define the window layout if you wanted to add commando support for your own tool? And presumeably, as you say, you could restrict what’s possible with the window interface as you deemed fit?

    • @someacnt_@lemmy.worldOP
      link
      fedilink
      04 months ago

      Seems like what I was roughly thinking of. I guess it fell into obscurity for good reasons, but I do think this kind of tool would be great for some edge-cases - that is, you cannot yet avoid terminal.

      • @tunetardis@lemmy.ca
        link
        fedilink
        English
        24 months ago

        The thing about the MPW Shell is it was sort of the only game in town if you actually wanted a command line with the classic Mac OS. (There’s an awesome little emulator called SheepShaver if you ever want to explore it btw.) Well, I suppose there was A/UX. I thought it was a miracle when that came out. You have to realize in those early days a good chunk of the operating system itself was actually baked in to ROM. (You had to do desperate things to squeeze a GUI out of such limited resources as existed back then!) So to this day I have no idea how they managed to spin off a 'nix despite that.

        Anyways. I wonder, if you made some sort of template format today, to what extent you could write some sort of conversion tool that would scrape a man page or whatever to rough it in and then you could tweak it to get what you want? man pages aren’t super standardized in their format I guess, so it’s probably more trouble than it’s worth. I like to use Python’s argparse when rolling out scripts myself, and its --help format is pretty rigid given that it’s algorithmically generated. Might be more plausible with something like that? I had a quick look just now to see if you can drill down into the argparse.ArgumentParser class itself to pull out the info more directly, but it seems a rather opaque thing that doesn’t expose public APIs for that. Oh well…

  • @nmtake@lemm.ee
    link
    fedilink
    44 months ago

    Long ago I made such restricted shell with filtering the shell command history file then disabling command history logging. With some shell scripting, I think you can get more sophisticated version. What shell are you using? (Bash, Fish, Zsh, etc.)

    • @someacnt_@lemmy.worldOP
      link
      fedilink
      34 months ago

      I am using bash, which is indeed part of the problem. What emulator would you suggest, and how did you achieve it?

      • @nmtake@lemm.ee
        link
        fedilink
        24 months ago

        Bash should be fine. On typical Bash installation I think this will work (please try to understand each command line before you actually try):

        $ cp ~/.bashrc ~/.bashrc.bak
        $ cp ~/.bash_history ~/.bash_history.bak
        $ printf 'set +o history' >> ~/.bashrc
        $ printf "sudo apt update\nsudo apt upgrade\n" > .bash_history
        $ (Press Ctrl+D to logout)
        

        For the next bash session you can refer only the two commands from the history with Up/Down/C-p/C-n.

  • @boredsquirrel@slrpnk.net
    link
    fedilink
    34 months ago

    I think you could get really happy with fish or at least bash history autocompletion.

    A flexible command runner, easy to add new buttons, spawning a terminal window to show the results, would also be useful.

    I agree on the issue

  • @k4j8@lemmy.world
    link
    fedilink
    34 months ago

    Interesting idea. If you really break it down, the “terminal with command buttons” is similar in concept to saving each of the commands as a script and putting those scripts in a directory to act as “buttons.”

    I’ve also seen some programs such as Kopia, a backup tool, that provide a GUI with the equivalent terminal commands for what is bring done shown at the bottom.

    I don’t think what you’re describing exists, probably because experts don’t need it and beginners would prefer a full GUI.

    There is Nushell, which promises more helpful error responses for the terminal, but its too early for it to be targeted at beginners in my opinion.

    • @Nibodhika@lemmy.world
      link
      fedilink
      34 months ago

      As much as I love nushell it will ever be too early for beginners, POSIX compliance is a big problem there. They have their very good reasons to not be POSIX compliant, but someone starting out should familiarize themselves with the most common pattern first before jumping to something completely different that will prevent them from running code snippets they might find online.