Well I was talking only about the command line concept, I made no mention of piping operations.

The command line mechanism as it stands today - including on Windows - is weak, out dated, clumsy.

I've been working on a proof of concept version for Windows, the design is that an app that supports command line args also supports an interactive menu that the user can tab around and fill in, every argument is visible and as one tabs around help text appears at the bottom of the displayed menu. The user can edit any field and the system validates keypresses according to the type of the arg, it also performs cross field validation and will not allow the user to submit any menu that's filled in illegally.

This was how VOS supported the command line and I've taken that and implemented a richer version that exploits color and so on.

Applications have very little to do, just describe their arguments, types and so on and call a parsing function.

The user can either use this in the usual way as a linear sequence of tokens and enter that, or they can request that the menu be displayed and us it that way.

I'll likely make this a .Net Core nuget package in the near future.

This is particularly helpful for seldom used commands or never before used commands where a user wants to see what the arguments are and get some idea of them before submitting the app, no need for the verbose and unwieldy pages of help text.

I'll put up a screenshot or two later.

 

Weak (nope), outdated (timeless), clumsy (to brain-dead people).

I can use the command line to do more than many apps. And while you may choose to ignore piping, it IS part of the command line. It like saying the alphabet is useless, because you choose nt t s vwls.

 

This is particularly helpful for seldom used commands or never before used commands where a user wants to see what the arguments are and get some idea of them before submitting the app, no need for the verbose and unwieldy pages of help text.

I don't see the use case for this. If I'm unfamiliar with a command and the short '--help' description of the arguments wasn't helpful enough, how is a color menu of the argument options going to improve matters? I'm going to have to read the man page or google the command to learn how to use it. And once I know how to use it, an interactive menu system would just get in the way. Maybe others would find it useful, though I'd think you'd need to integrate it into the shell to be most useful.

 

I don't see the use case for this. If I'm unfamiliar with a command and the short '--help' description of the arguments wasn't helpful enough, how is a color menu of the argument options going to improve matters? I'm going to have to read the man page or google the command to learn how to use it. And once I know how to use it, an interactive menu system would just get in the way. Maybe others would find it useful, though I'd think you'd need to integrate it into the shell to be most useful.

Colors are useful for all kinds of things, one could render required arguments red for example. The use case is basically ease of use.

It is impossible to invoke menu and enter a character into a numeric argument, it is impossible to mistype a range argument (like for example -optimize foul when the allowed values are full/medium/minor for example). It is impossible to submit the command with inconsistent args, for example -startdate 10-23-2020 -stopdate 10-19-2020 if the rule is that start date must always be before stop date, and its impossible to enter a date like 10-999-2020 because the menu editor wont let you.

Nothing "gets in the way" because it is optional, you do not have to go via the menu, it is a user's choice, simply append a semicolon and the system renders the interactive menu else it behaves as you'd expect it to.

e.g. typing this and <Enter>

test_program ;

causes this to be rendered:



Using tab and arrow keys I can get to any field and enter text or "cycle" args that support multiple fixed values:



If I press <Enter> at that point the app behaves exactly as if I'd typed:

test_program test.x -speed 123 -age Young

If I dont want to run the command after all I just press Esc and the app exits scrolls the screen a bit and the input prompt appears just under where the menu ends.

I've worked with command line based operating systems since the early 1980s and this (not my idea, Stratus implemented it when the ported Multics and created VOS) is a superb mechanism, especially for people unfamiliar with a command or app.

If you type some args incorrectly now in your system what happens? the app exits, displays some kind of text or error message and you must recall the line, edit it and resubmit it.

With the menu above (and that's just a pretty simple test example) you cannot submit the command with invalid args, it is not possible, I've only scratched the surface here for you, there is quite a lot more power here.

 

I've worked with command line based operating systems since the early 1980s and this (not my idea, Stratus implemented it when the ported Multics and created VOS) is a superb mechanism, especially for people unfamiliar with a command or app.

I can't see it being useful beyond a few special cases, though maybe people who absolutely despise the command line will like it.

If you type some args incorrectly now in your system what happens? the app exits, displays some kind of text or error message and you must recall the line, edit it and resubmit it.

Which still feels much faster than navigating a menu system, especially if I don't care about most of the menu options. I can't imagine what the menu for tar, which has like 60 complex options, would look like.

 

If I do repetitive tasks with complex command line parameters I work out the command line and make an alias or a small shell script. I have no problem typing --help and reading the results, then recomposing. The history makes editing and retrying easy. And "mistakes" aren't really the problem, getting the output I want is what usually takes a few tries.

Frankly, not of it seems like much of a burden.

Your idea might be useful as a "command line composer" for people not familiar with particular programs but I suspect if that was the interface I was forced to use, it would frustrate me. Your idea feels like those regex composers that people use. Some find them very useful, I just use a perl one-liner and I am just as fast if not faster.

I think there might be a place for it, sort of interactive documentation, but not for the things I do.

 

I can't see it being useful beyond a few special cases, though maybe people who absolutely despise the command line will like it.

As you wish.

Which still feels much faster than navigating a menu system, especially if I don't care about most of the menu options. I can't imagine what the menu for tar, which has like 60 complex options, would look like.

OK.

 

If I do repetitive tasks with complex command line parameters I work out the command line and make an alias or a small shell script. I have no problem typing --help and reading the results, then recomposing. The history makes editing and retrying easy. And "mistakes" aren't really the problem, getting the output I want is what usually takes a few tries.

Frankly, not of it seems like much of a burden.

Your idea might be useful as a "command line composer" for people not familiar with particular programs but I suspect if that was the interface I was forced to use, it would frustrate me. Your idea feels like those regex composers that people use. Some find them very useful, I just use a perl one-liner and I am just as fast if not faster.

I think there might be a place for it, sort of interactive documentation, but not for the things I do.

Well understand I'm not trying to sell this idea to you, if you like what you use currently and see no need for making it better or easier or less frustrating for some other users then fine.

 

The command line is decidedly not an archaic holdover for elitists. GUIs have their place, but the command line is all about facilitating automation and configurablility. When it comes to productivity, there's simply no comparison between command line and graphical interfaces.

You're preaching to the choir. As as been mentioned Windows is especially weak for scripting so I've written a couple dozen command line utilities that I live by, using constantly. (A grep-like tool for instance.) And I use the piping mechanism extensively. I am very appreciative to the Unix folks for their shell innovations, not to mention the work on the C language.

Still, I am able to discern which of my apps should be GUI and which should be "console apps". This is one area where Linux really falls short. At least a dozen years ago I was setting up a Samba share and there was a small GUI to tinker with some settings, but ultimately you needed to vi \etc\smb.conf to get it working. That is still the case today. Windows offers command line utilities for these things as well, but only hardcore guru's use them. I use the GUI to set ethernet settings for instance.

I have to keep a Linux cheat sheet. Here is my entry for setting up a Samba share:

sudo apt update
sudo apt install samba
sudo vi /etc/samba/smb.conf
[sambashare]
comment = Samba on Ubuntu
path = /
read only = no
browsable = yes
sudo service smbd restart
sudo ufw allow samba
sudo smbpasswd -a XXX

Good Lord, give us an idiot proof GUI to specify all the options for Pete's sake. And what psycho came up with sudo? I already entered my password when I logged in.

 

Good Lord, give us an idiot proof GUI to specify all the options for Pete's sake. And what psycho came up with sudo? I already entered my password when I logged in.

Hce you used Webmin? Even though I use the command line for most things, I use Webmin to manage configurations, I know many senior sysadmins who do.

 

Hce you used Webmin?

I'll take a look at it, thanks.

 

You're preaching to the choir. As as been mentioned Windows is especially weak for scripting so I've written a couple dozen command line utilities that I live by, using constantly. (A grep-like tool for instance.) And I use the piping mechanism extensively. I am very appreciative to the Unix folks for their shell innovations, not to mention the work on the C language.

Still, I am able to discern which of my apps should be GUI and which should be "console apps". This is one area where Linux really falls short. At least a dozen years ago I was setting up a Samba share and there was a small GUI to tinker with some settings, but ultimately you needed to vi \etc\smb.conf to get it working. That is still the case today. Windows offers command line utilities for these things as well, but only hardcore guru's use them. I use the GUI to set ethernet settings for instance.

I have to keep a Linux cheat sheet. Here is my entry for setting up a Samba share:

sudo apt update
sudo apt install samba
sudo vi /etc/samba/smb.conf
[sambashare]
comment = Samba on Ubuntu
path = /
read only = no
browsable = yes
sudo service smbd restart
sudo ufw allow samba
sudo smbpasswd -a XXX

Good Lord, give us an idiot proof GUI to specify all the options for Pete's sake. And what psycho came up with sudo? I already entered my password when I logged in.

A good solution to these kinds of things sometimes is to create your own interactive command loop, so called "REPL".

This is a console app (on Windows anyway) that internally exposes a number of sub-apps, a user can get into the app and then repeatedly submit sub-commands, see their output and so on. The main app retains all context and can retain state etc.

This is a bit like the Windows kernel debugger, complex command line applications can work well with this model.

 

A good solution to these kinds of things sometimes is to create your own interactive command loop, so called "REPL".

Many of my console apps work this way. I have extensive knowledge of parsing and lexical analysis so some of the command interpreters are quite elaborate.

I also have an image processing app that presents a GUI unless command arguments are passed in which case it executes a scripting language I added to it, and acts as a console app.

 

As I design this "command menu" system, it strikes me as neat to indicate switch vales (true/false) as +xxx and -xxx for xxx = true and xxx = false.

I've not seen this done yet it is tempting, on the older VOS system their command line parser recognized -xxx and -no_xxx which isn't bad either but the + and - seems better...

 

As I design this "command menu" system, it strikes me as neat to indicate switch vales (true/false) as +xxx and -xxx for xxx = true and xxx = false.

I've not seen this done yet it is tempting, on the older VOS system their command line parser recognized -xxx and -no_xxx which isn't bad either but the + and - seems better...

chmod accepts that sort of notation.

 

Why you keep personal external backups.
https://www.msn.com/en-nz/news/nati...etes-all-files-stored-on-desktops/ar-BB1eHgZV

Victoria University of Wellington has accidentally deleted all files stored on its desktop computers affecting a "significant" number of staff members - as well as some students.

A spokesperson for the University confirmed to Newshub on Thursday that an unexpected issue wiped all files saved on the desktops.

"The University's Digital Solutions team continues to work with all affected staff and students to recover access to files and in many cases the issues have been resolved," they said.

"There are however, some affected staff and students who have not been able to recover access to files."

The spokesperson did not answer questions related to grade compensation, and would not say how many people were affected.

The aim of the data wipe was to clear inactive users' data by getting rid of profiles of students who no longer studied, reports student magazine Critic.


Critic spoke to one Masters student who had heard of PHD students losing an entire year's worth of data.

https://www.critic.co.nz/news/article/9182/vuw-accidentally-wipes-desktop-computers

Staff first noticed the effects of the data wipe on Friday. At 1.48pm, Professor Joanna Kidman tweeted: “Really not wanting to panic anyone at VUW but have come into office to find that all my files have been wiped from my 'puter and IT is telling me it's a university-wide problem and it may not be fixed before Monday. Have a nice day.”

With ransomware usually after you pay you get your data back.

 

I once deleted all files on a system by accident. Fortunately, I pulled the plug as soon as I realized what I had done.

Never issue the command “rm -rf .”

Fortunately, DEC technical support were able to instruct me how to recover 100% of the files.

I met my wife for lunch and told her, incorrectly, that I lost my job.