3 ms·

The last thing I want in my shell script is to have it depend on a brand-new utility, which is part of the Rust ecosystem that is itself still new and evolving.

The last thing I want in my shell script is to have it depend on a brand-new utility, which is part of the Rust ecosystem that is itself still new and evolving. Shell scripts need to be super stable and portable. Edit: If I need GUI in my scripts, I'd probablyjust use dialog and other curses stuff.

mbirth 5y ago
Also most of the time I work via SSH on remote servers. I very much prefer any TUI over something I need to use X-forwarding for.
- MonkeyClub 5y ago
  I still prefer the plain question and answer approach. The OpenBSD installer follows it, for example, and makes for a very simple interaction. When SSHing to a remote host, it's quite snappy , and has no drawing overhead.
- jhgb 5y ago
  I mentioned the Gtk-server above. You might be able to use it across an SSH connection even without X forwarding.
ogoffart 5y ago
Imtui is not the same things as it is a C++ library, so you don't write shell code anymore, you write C++ dialog is an option but is quite limited in what you can do. There are many alternatives, and this is just another one to choose from. Depending on where your script is required to run, a Rust tool might not be a problem. Not all shell scripts need to be super portable.
- einpoklum 5y ago
  Yes, you're right about ImTui, removed that line. Disagree about portability. I mean, yes, you could write a shell script targeting even a single specific machine, but generally you want to assume as little as possible beyond a GNU operating system and its common utilities.
  - pjmlp 5y ago
    Beyond a POSIX operating system and its common utilities.
    - ogoffart 5y ago
      While it is true that some shell scripts need to be portable, many don't. Many shell scripts are written just to run in one single machine. Or they run in a controlled environment. Maybe even a docker container that provide anyway a set of tools and dependencies.
pie_flavor 5y ago
It's a native program; it's not going to morph out from under you. The Rust build system swears by semver compatibility, and crates.io is a permanent repository; it's not going to stop building. So what critique are you actually making, that {random C++ project} survives?

mbirth 5y ago

Also most of the time I work via SSH on remote servers. I very much prefer any TUI over something I need to use X-forwarding for.

MonkeyClub 5y ago
I still prefer the plain question and answer approach. The OpenBSD installer follows it, for example, and makes for a very simple interaction. When SSHing to a remote host, it's quite snappy , and has no drawing overhead.
jhgb 5y ago
I mentioned the Gtk-server above. You might be able to use it across an SSH connection even without X forwarding.

ogoffart 5y ago

Imtui is not the same things as it is a C++ library, so you don't write shell code anymore, you write C++ dialog is an option but is quite limited in what you can do. There are many alternatives, and this is just another one to choose from. Depending on where your script is required to run, a Rust tool might not be a problem. Not all shell scripts need to be super portable.

einpoklum 5y ago
Yes, you're right about ImTui, removed that line. Disagree about portability. I mean, yes, you could write a shell script targeting even a single specific machine, but generally you want to assume as little as possible beyond a GNU operating system and its common utilities.
- pjmlp 5y ago
  Beyond a POSIX operating system and its common utilities.
  - ogoffart 5y ago
    While it is true that some shell scripts need to be portable, many don't. Many shell scripts are written just to run in one single machine. Or they run in a controlled environment. Maybe even a docker container that provide anyway a set of tools and dependencies.

pie_flavor 5y ago

It's a native program; it's not going to morph out from under you. The Rust build system swears by semver compatibility, and crates.io is a permanent repository; it's not going to stop building. So what critique are you actually making, that {random C++ project} survives?