Like I said, you could abbreviate any way you liked as long as it was unambiguous. I think the ease of remembering meaningful words overrides the bit of extra typing It drives me more insane - and takes more time - looking up one-letter options that have no relation to what they do.
The great thing about the core philosophy of unix is that you could easily do what you suggest and maintain compatibility with applications that rely on the traditional coreutils (Which is the major reason why no one will really suggest changing the traditional syntax. It’ll break way too much.).
Just build a series of applications that actively translates your “less ambiguous” commands into traditional syntax. I’ve done it for a number of things where the syntax is long and hard to remember.
In fact I think a “nuutilus” would actually be fairly well received for distributions that are more new user focused and a pretty worthwhile endeavor.
I agree it’s definitely possible but I wouldn’t call it “easy” or describe it as “just build…”. If it were that that simple it would exist already - and possibly it does. In my DCL days - Digital Command Language, which I just remembered was the actual name of the VMS shell language - I had an elaborate set of shortcuts in my .bashrc equivalent, whatever it was called. But I don’t know bash anywhere near enough to take on creating a skin for it. Just making cheat sheets and gradually memorizing what I use most seems more realistic - and would be an easier process if the commands and options were more natural to begin with.
I say “easily” because it wouldn’t require a major effort on the scale of coreutils. It could just be a series of fancy automation scripts. It’ll take effort, but not the most intense of exercises.
I made a handful of them at an old job because we had a few specific tasks that we would regularly do, but not enough to commit it to memory. I just spent an afternoon here and there slapping together python scripts with just the options we would need and tossed it into /bin
Like I said, you could abbreviate any way you liked as long as it was unambiguous. I think the ease of remembering meaningful words overrides the bit of extra typing It drives me more insane - and takes more time - looking up one-letter options that have no relation to what they do.
The great thing about the core philosophy of unix is that you could easily do what you suggest and maintain compatibility with applications that rely on the traditional coreutils (Which is the major reason why no one will really suggest changing the traditional syntax. It’ll break way too much.).
Just build a series of applications that actively translates your “less ambiguous” commands into traditional syntax. I’ve done it for a number of things where the syntax is long and hard to remember.
In fact I think a “nuutilus” would actually be fairly well received for distributions that are more new user focused and a pretty worthwhile endeavor.
I agree it’s definitely possible but I wouldn’t call it “easy” or describe it as “just build…”. If it were that that simple it would exist already - and possibly it does. In my DCL days - Digital Command Language, which I just remembered was the actual name of the VMS shell language - I had an elaborate set of shortcuts in my .bashrc equivalent, whatever it was called. But I don’t know bash anywhere near enough to take on creating a skin for it. Just making cheat sheets and gradually memorizing what I use most seems more realistic - and would be an easier process if the commands and options were more natural to begin with.
I say “easily” because it wouldn’t require a major effort on the scale of coreutils. It could just be a series of fancy automation scripts. It’ll take effort, but not the most intense of exercises.
I made a handful of them at an old job because we had a few specific tasks that we would regularly do, but not enough to commit it to memory. I just spent an afternoon here and there slapping together python scripts with just the options we would need and tossed it into /bin