User-friendly command names

[ghost]

Allright y'all. We're reinventing the command line, and we should do it right - with human-readable and -rememberable command names. Let's add a new goal to the project goals: to finally address Donald Norman's criticism in his classic article "The trouble with UNIX" (http://www.linux.org.uk/~dan/rumor/rumor.shrink). Along this line, I suggested to Steven on Twitter that TermKit could have an optional layer that replaces standard command names (cp, mv, etc) with human-readable versions (copy, rename, and so on); he suggested I compile a list of replacement names.

The aim, I think, is to eliminate the need for manuals (and Googling) in 80% of cases. Obviously, manuals will never become obsolete, but we need to make a system where a casual user can simply type in what they want and get the right result in most cases.

Here are some ideas for command names:

• show should do what cat does in Steven's current screenshots - ie., display a file - when applied to a file; this might be implemented with less. When applied to a directory, it should be ls. It should still have the functionality of ls when passed multiple files as arguments - ie., it should list them - because it isn't cat: it won't combine files. Combining files is a much less popular action than showing them.
• copy for cp -r. I think being able to move directories should be the default, and the dir/ syntax for moving all the files in a directory (see http://en.wikipedia.org/wiki/Cp_(Unix)) should be removed; users should have to type dir/* to do that.
• rename and move for the two different functions of mv
• delete for rm -r. Users shouldn't have to remember a separate option for directories here, either.
• goto for cd and home for cd ~
• now for date and here for pwd
• set-system-time for the system-time-changing functionality of date
• link for ln. Remove the real link.
• possibly wait for sleep, though as @hach-que points out below this conflicts with another command.
• as-admin for sudo
• open for open on Mac OS X, and something similar on other platforms.
• edit, which would be like open is on OS X, but geared towards editing rather than viewing - eg. it would open your text editor for HTML files, your image editor for JPGs, and so on.

I think most commands should be verbose when in user-facing mode: for example, rename should show the new file(s), wait should have a countdown, etc.

Keep in mind this layer will be optional, so please don't comment pointing out that this would be annoying for experienced users. A nice user experience might be to have TermKit ask whether the user would like traditional or user-friendly commands when first launched, and to have the option be toggle-able in the Preferences thereafter. Per @cafarm below, it would also be nice to have an option that echos the underlying commands being performed, which you could toggle on for debugging and/or learning the old commands.

Two challenges that I'm not sure how best to handle are 1) creating files and directories (perhaps create dir/ for mkdir and create file (without the trailing slash) for touch?) and 2) searching for things: the problem is that grep and find are distinctly different, but both are expressed by the concept of 'search' or 'find'. What's the best way to distinguish between the two?

[hach-que]

I think I agree with the idea, but disagree on a few things :)

• show, copy and rename agreed (probably could have move as an alias of rename as well).
• delete should not be recursive considering you could easily accidentally wipe entire folders that you didn't mean to (have you ever hit the Enter key early, I know I have).
• goto should definitely stay as cd. goto doesn't really make a lot of sense, what are you going to exactly?
  • Same goes for here really since you don't need to know it (it's already implemented at the bottom of the terminal, for those that do need it can use pwd).
• now sounds good, especially since UNIX has a time command which doesn't really do what you think it would.
• set-system-time should probably be relegated to administrative tasks which I have an idea which I'll file later on once I've got the details worked out.
• link agreed.
• I would probably leave sleep since there's a wait command which waits for all asynchronous processes to complete before proceeding (which would be very useful in TermKit).
• as-admin I think can probably be better named to something more suited to general purpose "run as another user" type tasks. as-admin isn't going to make much sense if you're actually switching to another user (probably more important in a Windows-based environment where you can have multiple types of administrators).
• open agreed.
• edit is a tricky one in terms of implementation. I'm not sure about Mac OSX, but in Windows it would be fair difficult to work out exactly what editor matches what file type (since the only thing you've got to go by is context menu entries, and sometimes editors don't add themselves to it).

I think for the create it would actually probably be best dealt with as an argument toggle (-d for example). As for grep / find I think we should have grep built into find as a "find inside files" modifier (i.e. only show files which contain this text), which would leave us with just find.

[ghost]

Thanks for your comments!

• Yep, agree on move - have added that in.
• Steven mentioned that warnings about harmful actions, like accidentally deleting entire folders, would be dealt with separately, so I'm ignoring those possibilities for this discussion. It would be better if delete meant rm -r and TermKit warned you about possible problems than if it didn't and the user had to remember to type -r every time.
• Disagree on cd - acronyms are crap, and goto /this/place/in/the/file/system makes perfect sense. Perhaps it should be go-to.
• I like here as a complement to now and when you need to find your current directory, perhaps in a script.
• I didn't realize wait existed - that's a good point, I've mentioned it in the list.
• re as-admin: perhaps another more general command would also be useful, but running commands as the administrator account is such an essential task on OS X that it merits its own command.
• Having an argument toggle for create is not nice; argument toggles in general are awful UX. I think the dir/ vs file distinction is clearer.
• I kind of like the idea of unifying grep and find - can you post a couple examples of how you envisage the various functions working?

I'm going to try and keep the list at the top of the page up-to-date, incorporating everyone's suggestions and comments.

[hach-que]

I think however, that the user might end up typing create dir and realise that instead it created a new empty file. I'm actually not really sure what use-cases there are for creating an empty file though (you can achieve the same using echo "what you were going to put in there" > file anyway).

As for find, it would probably be something like:

find [--infiles] pattern paths

or something to that effect (I still think that argument toggles are useful especially since we now a UI which we can actually indicate the purpose of a toggle in TermKit itself when it's used). Alternatively we can also provide them via AutoComplete.

[cafarm]

I think its important that after you enter the command with the human readable name, TermKit spit back the real underlying command before executing. This will help unix newbies and experts alike.

[ghost]

That wouldn't make sense. If you want to learn the old ways, you should simply choose the 'traditional' setting on install.

[cafarm]

I don't see why this couldn't be a way of learning so you're not completely lost if you're in front of a terminal without TermKit. Also, it would help you diagnose problems if an abstracted human readable command isn't doing what you expected. You can look up "rm -r" on Google. You can't look up "delete"... especially if it changes the underlying command based on the context of how you use it.

It can be completely transparent to users who aren't interested in it. Perhaps it can construct the real unix command on a separate line in real time as you type your human readable command.

[ghost]

You're right, it'd be real helpful for debugging. It has to be off by default though; echoing alphabet soup at a new user is going to destroy their interest in using TermKit. Have added to top comment.

[hach-que]

One issue with showing the command equivalents is that they're totally irrelevant on a different system (we'll likely end up having Linux, Mac OSX and Windows ports). The command to copy a directory recursively and ignoring errors is different on both Windows and Linux; indeed the former has a lot more options relevant to that specific system (such as how to handle networked files).

In the event that someone suggests "we should just let the person writing the command to specify the equivalents", an issue is raised when the command writer doesn't know the equivalent commands, or more importantly, provides the wrong information.

I think it's probably best to not show equivalent commands in TermKit. Eventually TermKit will do remote connections over SSH, so you won't need to deal with the issue of "I don't have a TermKit in front of me" because of that (the other situation is when you're using someone else's computer, but in that case there's a lot of other things that can go wrong such as different distros and available software).

[unconed]

Looks good, thanks everyone for your input. I will try and get this working soon.

As for the issue of whether we should clarify the mapping to traditional commands... here's how I see it:

TermKit's goal is to be a more usable command shell. Therefor it seems logical to me that it should present commands like "show", "now" and "here" as if they were native, and act universally across platforms. If this means wrapping a different native command on each platform, so be it, but obvious we should aim for uniformity and least-invasion wherever possible.

As for scripting, I've explained elsewhere that I feel Bash is a terrible scripting language, and trying to make something that does both command execution and full stateful scripting is a bad idea. I'd much rather just type "node" or "ruby" and go into a sub-shell where I get autocompletion and rich output for that.

The number of cases where you have to invoke traditional unix utilities in script are much less when you have a real standard library at your disposal. But if you still want to, it shouldn't be too much of a problem. In theory, nothing prevents TermKit's node.js built-ins from being run stand-alone (headless) just by adding an appropriate preamble. Thus, we can implement most of these as aliases, and implement the platform-unifying ones as built-in commands that can run stand-alone. You get the best of both worlds. Some magic glue will be required, but I think it can be done.

[d3x7r0]

here could be whereami since at least on linux you usually have the corresponding command whoami to know which user you're logged in under

[CoderPuppy]

as-admin could be generalized to as-user passing in the user to run it as. admin could then run it as admin basically sudo.