This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: svlug@svlug.org
Subject: Re: [svlug] About mc (and other linux file managers)
Date: Sat, 19 Jan 2002 11:10:57 -0800
From: Joe Brenner <doom@kzsu.stanford.edu>
J C Lawrence <claw@kanga.nu> wrote:
> Loosely what I want is single pane, single directory view with the
> ability to interactively (in the move the cursor about and hit
> command keys sense) copy, move, rename, etc files with a very fast
> large file viewer that doesn't insist on loading them into memory.
> If the command keys are letter based (c=copy, d=delete, m-move,
> r=rename, etc I'm fine and configurability is not needed. I don't
> want to launch editors, run scripts, or handle spiffy regxes -- just
> text mode point, select, and shoot. Not particularly interested in
> an internal command line. Don't want help. Copy destination can be
> typed in, or can be walked to and then copy invoked. Can't think of
> any reason I'd be interested in ALT-TAB.
I'm trying to figure out why "dired" isn't in the running
here. I would think it does everything that you're asking
for here, though of course it also does a bunch of things
you're saying you don't care about it... (I'm not sure why
you don't, but that's up to you.)
One of the reasons I use dired of course, is that I also use
emacs, and the two are integrated very well (like, for
example, if I'm editing a file, and go change the name of
the file in dired, emacs knows about it and the open buffer
gets associated with the new name). There is also a
standalone version of dired, though I have to admit I'm not
too familiar with it. I don't know if it has all of the
customization features you expect from emacs.
===
To: Joe Brenner <doom@kzsu.stanford.edu>
From: J C Lawrence <claw@kanga.nu>
Subject: Re: [svlug] About mc (and other linux file
Date: Sat, 19 Jan 2002 13:40:54 -0800
On Sat, 19 Jan 2002 11:10:57 -0800
Joe Brenner <doom@kzsu.stanford.edu> wrote:
> J C Lawrence <claw@kanga.nu> wrote:
> I'm trying to figure out why "dired" isn't in the running here.
It kinda is and mostly isn't. The main reason its not is that I'm
not in XEmacs when I have an interest in file management, I'm in a
bash shell and I've little/no interest in running gnuclient at that
point just to bring up an XEmacs for a few seconds.
> I would think it does everything that you're asking for here,
> though of course it also does a bunch of things you're saying you
> don't care about it... (I'm not sure why you don't, but that's up
> to you.)
Aye, it does it all, it just does them all inside of XEmacs and I'm
not in XEmacs when I want to do those things.
> One of the reasons I use dired of course, is that I also use
> emacs, and the two are integrated very well (like, for example, if
> I'm editing a file, and go change the name of the file in dired,
> emacs knows about it and the open buffer gets associated with the
> new name).
Yup, done that. (XEMacs user here)
>> The emphasis is on speed and simplicity. One of the things I
>> really miss is an equivalent to 4DOS/4OS2's "select" command.
> Describe how it works and I'll write an emacs extension for you
> that does it.
See prior post with details.
Problem: I don't want to do it from inside (X)Emacs.
===
To: svlug@svlug.org
Subject: Re: [svlug] About mc
Date: Sun, 20 Jan 2002 16:43:27 -0800
From: J C Lawrence <claw@kanga.nu>
[...]
>> LIST (which I last used ~8 years ago under DOS and OS/2) does
>> what I actually want.
> I don't get it. What is it that LIST does that mc does not?
Faster, smaller, lighter, more unobtrustive, easier/more-intuitive
cross-directory operations, default/expected key bindings, less
cruft. I don't want a swiss army knife. I just want a small fruit
knife.
[...]
===
To: svlug-admin@lists.svlug.org
Subject: Re: [svlug] About mc
Date: Sun, 20 Jan 2002 16:43:27 -0800
From: J C Lawrence <claw@kanga.nu>
[...]
>> mc enforces a UI which I find nearly unusable and supports a raft
>> of features that I find distracting from what I'm
> ? every UI program enforces its UI. every CLI program enforces
> its UI as well. LIST does. not sure why you are singling mc out.
Because I don't like mc's choices?
> the extra features: you don't have to use them. mc presents you
> with two (or one) panels with lists of files that you can fairly
> easily perform basic file operations upon (if you don't remember
> keys just look at the status line). you don't even have to know
> about any other fancy features. how is something that you never
> see on the screen distracting you?
Silly examples: The may MC handles cross-directory operations is the
exact opposite of what I prefer. mc requires the other pane to be
on the target and the current pane to be the source. Aaaargh! That
catches me almost every time. The second confirm/edit/etc step
under mc when doing a tagged file operation is something I've never
wanted (or used) and would really like to never see.
ObNote: I'd also much prefer it if mc left me in the directory it
was viewing when I exited, rather than the directory I started it
from.
> you can fire it off anytime you want and quit it with single
> keystroke, it's not a monster that would take forever to start up:
Arguably that's little different from list.
[...]
> also: menu bar, command line, status line, hint line can all be
> turned off so you're left with panel(s) only.
I'd rather (almost always) have visible the bottom end of scrollback
(usually the last 20 or 100 lines depending on window size, with a
further 5K lines available under PgUp/PgDn)). That I find useful
and use dozens of times a day. The vast majority of the time I
don't have a use for the panes.
[...]
===
Date: Sun, 20 Jan 2002 23:42:53 -0800
From: Marc MERLIN <marc_news@vasoftware.com>
To: svlug@svlug.org
Subject: Re: [svlug] About mc
On Fri, Jan 18, 2002 at 11:23:13PM -0800, J C Lawrence wrote:
> Not quite. While mc does have some keyboard rebinding as we went
> over the last time round, it doesn't support keyborad binding to the
> extent I want (rebinding alpha keys).
True, just like vi, there are commands that you only get with
CTRL-X CTRL-key, and you can't change 'key' easily
On Fri, Jan 18, 2002 at 11:58:17PM -0800, J C Lawrence wrote:
> Loosely what I want is single pane, single directory view with the
> ability to interactively (in the move the cursor about and hit
> command keys sense) copy, move, rename, etc files with a very fast
which mc can all do, in a single pane if you wish.
> large file viewer that doesn't insist on loading them into memory.
Neither does mc's
I actually use mc's viewer to do binary in place edits, and they are done on
the right disk block without loading the file in memory.
> If the command keys are letter based (c=copy, d=delete, m-move,
> r=rename, etc I'm fine and configurability is not needed. I don't
Different philosophy. With mc, alphanum keys go in the command line since
you can build a command line at all times (equivalent of the select command
line you were talking about), so obviously you can't use c for copy, you
have to use some other key.
But eh, you're fond of mc, regardless of technical attributes, so for you it
is going to be better.
> want to launch editors, run scripts, or handle spiffy regxes -- just
> text mode point, select, and shoot. Not particularly interested in
mc does that.
> an internal command line. Don't want help. Copy destination can be
Well, you get both.
> typed in, or can be walked to and then copy invoked. Can't think of
> any reason I'd be interested in ALT-TAB.
With mc, you can type "cp", select your files, CTRL-X T, and type the
destination if you with (including tab completion)
> The emphasis is on speed and simplicity. One of the things I really
Anyone who sees me use mc usually can't follow what I do :-)
It's all about knowing the tool.
On Sat, Jan 19, 2002 at 02:57:42AM -0800, Erik Steffl wrote:
> which offers better navigation (searching, marks etc)). I just tried to
> open 22MB file (kernel bz2) and it opened it in lot less then 1 second,
> so I am pretty sure it does not load the whole file into memory, at
> least not in the beginning.
It does not, you can open /dev/sdax, and it'll load block on demand, as it
should.
On Sat, Jan 19, 2002 at 01:36:32PM -0800, J C Lawrence wrote:
> The bindings I'd like would be something like:
>
> ENTER -- (on file) less, on directory CD
> SPACE -- tag
> C -- copy
> D -- delete
> M -- move
> R -- rename (mv)
> L -- hard link
> Q -- quit
> S -- sym-link
This is clearly incompatible with the command line feature in mc, which you
may not use, but that's not the point.
> I have use for a file manager no more than once or twice a month.
I can do complex copies, moves and rename with mc faster than you can type
them.
> > It is kinda arrogant from a program to not let you assign any
> > keybindings but IMO it's not serious usability problem.
>
> I generally consider it critical.
I guess that's why you use emacs and not vi then :-)
I, for one, am damn happy that vi users don't get to remap all the keys to
anything they'd like, otherwise it'd be a complete mess.
On Sun, Jan 20, 2002 at 04:43:27PM -0800, J C Lawrence wrote:
> > in mc they are right in front of you. you don't have to learn
> > anything.
>
> I find myself having to read the function key labels near every
> time. I'd rather not, especially as they're abbreviated.
Tss, tss...
> Silly examples: The may MC handles cross-directory operations is the
> exact opposite of what I prefer. mc requires the other pane to be
> on the target and the current pane to be the source. Aaaargh! That
That's how most people seem to want it, but if you really want to, CTRL-U
will exchange both panes, but mc was meant to emulate nc, so it does behave
the same as a result (only better)
> catches me almost every time. The second confirm/edit/etc step
> under mc when doing a tagged file operation is something I've never
> wanted (or used) and would really like to never see.
Well, then instead of complaining, you could go in the Options/Confirmation
menu, and disable them.
> ObNote: I'd also much prefer it if mc left me in the directory it
> was viewing when I exited, rather than the directory I started it
> from.
Then it wasn't installed properly.
In Red Hat and Debian:
root@gandalf:~# type mc
mc is a function
mc ()
{
MC=/tmp/mc$$-"$RANDOM";
/usr/bin/mc -P "$@" >"$MC";
cd "`cat $MC`";
/bin/rm "$MC";
unset MC
}
> Arguably that's little different from list.
>
> > jojda:~>time mc
>
> $ time mc
> real 0m0.469s
> user 0m0.000s
> sys 0m0.040s
On my system,
real 0m0.239s
user 0m0.050s
sys 0m0.020s
but who's counting?
Both are plenty fast, and quibbling about sub second launch time, coming
from an emacs user is middly ironic I think...
===
Date: Sun, 20 Jan 2002 23:48:18 -0800
From: Erik Steffl <steffl@bigfoot.com>
To: svlug@svlug.org
Subject: Re: [svlug] About mc
J C Lawrence wrote:
>
> On Sat, 19 Jan 2002 23:58:50 -0800
> Erik Steffl <steffl@bigfoot.com> wrote:
> > J C Lawrence wrote:
> >> On Sat, 19 Jan 2002 02:57:42 -0800 Erik Steffl
> >> <steffl@bigfoot.com> wrote:
>
> >> I have use for a file manager no more than once or twice a month.
> >> I'm not going to learn the keys, and if I do I'm unlikely to
>
> > in mc they are right in front of you. you don't have to learn
> > anything.
>
> I find myself having to read the function key labels near every
> time. I'd rather not, especially as they're abbreviated.
? most of them are not:
1Help 2Menu 3View 4Edit 5Copy 6RenMov 7Mkdir 8Delete 9PullDn
10Quit
the only confusion is menu <-> pullDn (menu is user menu, pull down is
the application menu).
a little bit more detail about function keys (Fn <-> esc-n):
mc uses ctrl and meta modifiers, if meta is not available it uses esc
(esc, then key). since the function keys are not as common and generally
it's harder to make them work the meta n (n=1, ..9, 0) double the
function of Fn. So the safest bet is to hit esc-n, that should work in
most situations. I wasn't sure why you dislike function keys - if the
reason was that they are not as widely available (or don't work) then
esc-n would be a good solution.
as far as speed goes you can also use meta-n instead, that way you do
not have to leave the home row. on debian (i386 arch) the meta seems to
be the window key (at least that's what it is on my system and I don't
remember doing any changes in this area). it's still not as good as
whatever you want it to remap to but it's somewhat better as far as
typing goes.
...
> > it doesn't limit you in any way and it's simpler than ctrl-z
> > etc. (nothing prevents you from using ctrl-z though).
>
> Except that Ctrl-Z works everywhere, with everything.
so use it with mc just like you would with list. it's hardly a fault
of mc that it provides additional functionality (that does not limit you
in any way).
...
> > generally traversing the directory trees is easier using file
> > manager (less keystrokes, you see what's happening)
>
> TAB completion is your friend. ido.el under (X)Emacs make it
yes, but not a (boy)|(girl)friend/spouse, i.e. it's ok to have more
than one friend.
...
> > not modern destop design, modern desktop machines: there are no
> > space (HD or RAM) constraints that would excuse lack of readily
> > available on-line doc (man page, context sensitive help etc.). how
> > else would you learn how to use a program?
>
> A man page is not context sensitive help. However it, and perhaps a
> README, is enough for the majority of cases. For the rest throwing
> something under /usr/share/doc handles most other cases.
for a gui program there is no excuse not to have context sensitive
help. why should a user have to go someplace else and go through
irrelevant info when program knows exactly where the user is a can
provide relevant help information?
> >> SELECT <file-spec> <command>
> >>
> >> Brought up a scrolling text list of the matching files which
> >> could be cursored among and tagged/untagged with SPACE. Hitting
> >> ENTER ran the provided command on all tagged entries.
> >>
> >> That alone under bash would remove 90% of my need/wish for a file
> >> manager (I faintly understand you can do something not entirely
> >> dissimilar under zsh, but I haven't looked into that yet).
>
> > it's not exactly the same but that kind of functionality is
> > covered by command line auto-completion,
>
> Aye, that's a standard (and heavily used) feature here. it doesn't
> do much however for the "I want to run this command on some
> arbitrary selection of those files" case.
mc can be used then, even though the order of operations is slightly
different:
1: mc
2a: select files
2b: type the command
3: hit ctrl-x t<enter>
then F10 if you don't want to use mc anymore...
it has the same effect as you describe, it's a little bit less
effective as far as typing goes (but not much) - it shouldn't matter if
you use it rarely, if you'd use it more often you would probably already
be in mc.
2a and 2b can be done in any order.
2a: there are several ways to select files you want to use:
insert tags/untags files
+ enables you to type in shell patter or regexp (configurable)
meta-? is a simple version of find+grep
ctrl-x ! let's you run any program that returns list of files (e.g.
find)
you do not have to use all the fancy file picking mechanizms, if you
want to stay simple you can use insert and possibly +
3: you can edit the resulting command line before hitting enter
(unfortunately not using your shell, it gets into shell history though).
you have to know the ctrl-x t spell though. then again, you have to
know select if you want to use it so it's basically the same (and
there's context sensitive help in mc when you forget the keybinding).
note that while what I describe is somewhat complicated you can use it
in very simple form, in that case it's basically the same as select. the
additional functionality does not stand in your way...
...
> Err, to repeat the point, I don't. File management is perhaps less
> than 3% of my time, if that.
what I was saying is that I am not all the way on the other side (as
you suggested). In fact if it weren't for mc I would probably use file
managers less than 10% (at least that was the case before I've found mc)
and be quite happy.
...> > I don't get it. What is it that LIST does that mc does not?
>
> Faster, smaller, lighter, more unobtrustive, easier/more-intuitive
> cross-directory operations, default/expected key bindings, less
> cruft. I don't want a swiss army knife. I just want a small fruit
> knife.
smaller: yes (but who cares?)
faster: NO, see the timing of startup/exit below, and there doesn't
seem to be any detectable speed difference during operation.
more unobtrusive: mc even let's you work in your shell, how can it be
any less obtrusive? you can have nothing but panel on the screen...
intuitive: list is not intuitive at all, without using the help screen
you wouldn't be able to do almost anything. 'c' does not copy. v is for
NV (arc viewer) [linux version, IIRC it is somewhat better in DOS
version] etc. mc is not anymore intuitive than that but at least it is
easy to get help, it displays basic keys on the screen (if you want it
to) and lot of keys are the same as nc uses (which is/was sort of de
facto standard)
cross directory ops: linux list doesn't seem to have any. haven't find
a way to copy a file (intuitive???). what I remember from dos version is
that it brings up dialog where you can type in the destination, which is
exactly what mc does. mc provides the oposite panel's directory as
default but you can start typing your own destination right away so it
doesn't slow you down at all, it even provides auto-completion
(meta-tab).
key bindings: list definitely does NOT provide expected key bindings,
specially the linux version. the dos version - perhaps and if you like
those then that's a valid point against mc. still - you cannot change
them so how is it that you know what to expect when you hit r? is it
remove or rename? intuitive?
the knife analogy is not a valid one in this case. the extra
functionality of mc does not come at significant cost - the only
difference is that the program is bigger, it does not have almost any
difference on start-up time (that's the only possible difference). the
HD space it takes up is not of concern (today and even less concern in
the future). How is the extra functionality of mc standing in your way?
If you don't know about the extra keybindings you simply don't use them.
What's the problem?
...
> >> mc enforces a UI which I find nearly unusable and supports a raft
> >> of features that I find distracting from what I'm
>
> > ? every UI program enforces its UI. every CLI program enforces
> > its UI as well. LIST does. not sure why you are singling mc out.
>
> Because I don't like mc's choices?
in one panel configuration it is basically the same as list...
...
> Silly examples: The may MC handles cross-directory operations is the
> exact opposite of what I prefer. mc requires the other pane to be
> on the target and the current pane to be the source. Aaaargh! That
(sort of repeated from above) no it does not. it just provides it as
default, you can immediately type in your own destination just as if the
default wasn't there. it even provides auto-completion. what more (or
less) do you want? how is list better than that?
> catches me almost every time. The second confirm/edit/etc step
> under mc when doing a tagged file operation is something I've never
> wanted (or used) and would really like to never see.
you get the same dialog in list. how else would you specify the
destination? it does not make any sense. what do you mean?
> ObNote: I'd also much prefer it if mc left me in the directory it
> was viewing when I exited, rather than the directory I started it
> from.
list or any other program does not do that either. and cannot. that's
why cd is internal shell command (child cannot change the parent process
environment, cwd etc.)
however, there's a sort of solution for this, here's a relevant quote
from man page:
-P At program end, the Midnight Commander will print
the last working directory. This function should
not be used directly, instead, it should be used
from a special shell function that will automati