export MARKPATH=$HOME/.marks
    function j {
        cd -P "$MARKPATH/$1" 2>/dev/null || echo "No such mark: $1"
    }
    function mark {
        mkdir -p "$MARKPATH"; ln -s "$(pwd)" "$MARKPATH/$1"
    }
    function unmark {
        rm -i "$MARKPATH/$1"
    }
    function marks {
        \ls -l "$MARKPATH" | tail -n +2 | sed 's/  / /g' | cut -d' ' -f9- | awk -F ' -> ' '{printf "%-10s -> %s\n", $1, $2}'
    }
    function _jump {
      local cur=${COMP_WORDS[COMP_CWORD]}
      local marks=$(find $MARKPATH -type l | awk -F '/' '{print $NF}')
      COMPREPLY=($(compgen -W '${marks[@]}' -- "$cur"))
      return 0
    }
    complete -o default -o nospace -F _jump j

The more I use the command line, the more I type full path on my commands. So (when I recall them from history) I can run them from anywhere.

Next step is to store path in variables, and my command lines contain the variable instead of the path (depending whether I want the history to include the variable or the path, I will Ctrl-Alt-e the commande line before running it).

Next step is to define functions to aggregate several command lines together. And be able to replay them later. (I built a small utility to make it super simple, otherwise it is a complex time-consuming process to define and manage functions in shell).

Next step is to separate those functions into several local accounts, so tasks (and bash history) are cleanly separated.

Next step is to use screen/tmux to have one (or more) shell open for all those local accounts. (i usually have a "master" tmux, with one window per user, and each user can launch its own tmux inside it).

That sounds insanely complex. But I find a kind of calmness now. My tasks are organized by user, histories are very semantic (each command line is a function name, very few "cd" or other non-meaningful commands).

And when I need to type commands, I think whether I will go the usual way (aka the _quick and dirty_ way). Or if I will build a clean workflow so I can replay my commands later.

1. Type part of a command and search the history: I often have to run a mysqldump + mysql load on a couple databases, and the command is quite long. If i just type `db1` and press up arrow, fish will load the command 'mysqldump -uxxx db1 | mysql -uyyy local_db1'. I don't have to create functions to do complex, common shell commands, as long as they have keywords I can use to look them up.

2. Search the history based on the current path: Suppose I have two directories, `app1` and `app2`, each with a `run-appX` executable. If I enter `app2` and I type `.`, fish will autocomplete it to `./run-app2`, because the history is context dependent, and it knows there's a `run-app2` file I've often referenced while in the `app2` directory.

Haven't found a way to replicate these two behaviours in any other shell as well as fish does, and I don't have to create separate functions for most of my workflow. fish takes care of that.

The first one probably has an equivalent in Bash with Ctrl-R and typing (and Ctrl+R again to cycle through matching lines)

The second one is new to me. Cool!

“cd .. {Enter}” in console is either “{Alt}+{Up arrow}” or “{Home} {Enter}” in GUI, 6 versus 2 key presses. “cd de{tab}” in console is “d e” or “{Alt}+d e” in GUI, 6 versus 2-3 key presses.

GUI tools are able to expose shorter commands because context is richer, i.e. user instantly sees a filter edit box popping up after {Alt}+d, user will see both current location + child items after each navigation or filter operation, etc. That kind of interactivity is what saves user input. The approach is hard to implement in a shell because shells were designed for command-output interaction model. OTOH, rich GUI tools are much harder to develop.

TC has better archives support, and better F3 previews for pictures and multimedia.

Far has slightly better FTP client, includes SCP client, has _much_ better F4 editor, and also has seamless command-line shell integration, i.e. Ctrl+O switches between blue panels and interactive shell, with synchronized current directory and commands to insert file names/paths into the shell prompt.

While indeed limited, it’s not limited just to navigation. Here’s a GUI that appears when I press Alt+F7 in a GUI file manager: http://const.me/tmp/tc-find-gui.png

It exposes combined functionality of many Linux shell utilities: find, grep, lsattr, xargs, fdupes, iconv, mountavfs/fusermount, etc.

For example I click “{Alt}+(F7 r t) test {enter}” to find all files containing “test” in all files and subdirectories, including content of archives. That’s 9 key presses. Can you do equally efficient in a command line shell?

Not only it saves key presses, its also less stuff to remember and therefore much easier to use. I only need to remember Alt+F7, the rest is obvious because labels, and by convention, underlined letters in them mark {Alt}+{Letter} shortcuts. You don’t even need to use keyboard, mouse is even more accessible (but not touchscreens, for them entirely different GUI is required).

Can you do equally efficient in a command line shell?

Well, of course; that's what aliases are for.

Not only it saves key presses, its also less stuff to remember and therefore much easier to use.

No argument there; I was disagreeing with a specific point, not making a case for the overall superiority of the shell.

That screen is not limited to navigation commands. By using keys other than enter, I can copy, rename, delete, e-mail, pack, etc. that de-whatever directory. Each of the operations would take just a couple extra key presses.

Technically you can do the almost same with TUI (but not CLI) but still less efficient because sometimes file icons and especially previews deliver valuable information to the user.

> Well, of course; that's what aliases are for.

How easy is gonna be to write a command for that alias that does same as “{Alt}+(F7 r t) something {enter}” in the above GUI? The GUI supports zip, rar, tar.gz, cab, and many others out of the box, plus plugins for other archives (I only have 7-zip).

Another thing, a single alias is not enough to replace the GUI, because behind that not so complex looking GUI there’s a functionality with 20 parameters just on the first tab page. Even if you’ll create that alt-f7-r-t alias, next day you’ll need to do same but search for UTF16 and/or regexp and/or case sensitive. How you’ll deal with the exponential explosion of complexity? With equally complex CLI with arguments like -rwe2hoc18m? Not many people use advanced searches every day, so memorizing the switches is not worth it. Most users will have two choices, read manual each time, or write commands instead of using that search alias. Both options are significantly slower than using Alt+F7 GUI screen.

The shell also uses keys other than enter; in fact, the enter is only use once per command :)

Some will be more efficient, others will be less. Copying a file in the same directory, for example, means pressing the first letters of its name, then CTRL+C, then CTRL+V, then F2 (or whatever "rename" is bound to), then the new name, then Enter. In the shell, it's "cp ", then the first letters, then Tab, then the new name, then Enter. Not really that different.

> How easy is gonna be to write a command for that alias that does same as “{Alt}+(F7 r t) something {enter}” in the above GUI?

From what I can tell, that operation does the equivalent of "grep -R something ." no? Why would that be hard to write an alias for?

> The GUI supports zip, rar, tar.gz, cab, and many others out of the box, plus plugins for other archives (I only have 7-zip).

You can use 7z on the shell to do the same. Why would you think that's specific to the presentation mode?

> Another thing...

You keep insisting on discussing the overall merits of the shell vs GUI. I told I'm not interested in that, I was only disagreeing with a specific point. Yes, the GUI is more discoverable, I already wrote "no argument there".

I know, and I was answering to your statement “That screen is limited to navigation”. It’s not.

> that operation does the equivalent of "grep -R something ." no?

No. With “search archives” checked you can run that in a directory with multiple archives of different types, some of them containing other nested archives, it’ll recursively unpack everything (in a streaming manner, without wasting HDD with temporary files), and produce a list of files (possibly files inside these archives) containing that text.

Technically you can use 7z+others, write a huge script to combine them together for similar functionality, but it’ll take hours to develop.

    mcd () {
        mkdir -p "$*" && cd "$*"
    }

Note: the name overrides the GNU Mtools' mcd (https://www.gnu.org/software/mtools/manual/mtools.html#mcd) on some systems – choose another name if you need the tool. The original mcd "changes MSDOS directory" according to it's manpage, and wants to do something with a floppy drive when i run it by mistake.

Completions are remembered, so if your project has ever had the same setup, cd will predict for you, and be a couple keystrokes away.

ls ~/Dev<TAB>/<TAB><TAB>pro<TAB>

I guess cd would waste a lot of my time if I was cding everywhere to just "look around".

If I need workspaces I save a tmux session.

Is that aight? Is j good for more u predictable patterns? I’ll give it a shot

> Directories must be visited first before they can be jumped to.

Well that's annoying..