Unix/Linux

NAVIGATION
CATEGORIES
REFERRENCE
LINKS
  • mc = Killer Ap !

    3 answers - 5343 bytes - related search similar search Add To My Delicious Add To My Stumble Upon Add To My Google Mark Add To My Facebook Add To My Digg Add To My Reddit

    n@absamail.co.za wrote:
    This clown-discussion perfectly illustrates the point which
    I've previously been making.
    Without remembering the detailed syntax of 'find', I can see that
    you want to backup the '*.for' files from a tree [possibly a single
    dir].
    Consider:
    You have a bowl containing some few dozen glass marbles, red, blue,
    yellow, green.
    Your task is to move the red marbles to a 'bakup-bowl'.
    For files which can be copy [ie. duplicated] as well as moved,
    the principle is the same.
    Here's the algorithm:
    1. get the 'bakup-bowl'.
    2. look into the 'bowl containing the glass marbles'
    3. If you 'recognise' a red one, move it to the 'bakup-bowl',
    else stop.
    4. repeat step 3 !
    Ie. YU JUST LK AND D IT !!
    Like when you put sugar in your coffee cup.
    You DN'T write a 4 line message to the little man in the box !!
    And that's how you do it with mc.
    Instead of using/remembering the crap-syntax of 'find' and 20
    other linux commands.
    Jean-David Beyer wrote:-
    The syntax of _find_ is not all that difficult for a problem like
    this.
    Another program that would be faster and easier, if you wanted _all_
    programs with a _.for_ suffix would be _locate_ where
    locate .for
    would suffice.
    The reason I mention it is because I do not seem to have _mc_ in my
    distribution at all (RHEL 3). I know for sure that _nautilus_ which
    is slightly like _mc_ would not do it for anything other than a
    directory that
    would fit on the screen, and would not handle recursion in any
    practical way.
    My machine has about 1/4 million files, and I imagine this number is
    relatively small compared with what some users have. I cannot imagine
    using
    a point and click interface to find all of anything in there. So if I
    wanted
    to backup all the _.for_ files, and did not wish to use my normal
    backup tool (BRU), I would use something like
    locate .for | cpio
    >/dev/st0
    >

    If I wanted only a subset of the _.for_ files on a machine, I suppose I
    might use grep in the pipeline between the _locate_ and the _cpio_
    (but I
    doubt it). I am sure I would use _find_ which is not all that much
    trouble,
    but you do not want to hear about that.
    Actually, I probably would do _none_ of these. If I did a backup of less
    than all my files, the ones I would need from the backup would be the
    very ones _not on the backup tape_ (by Murphy's Law), so I backup
    _everything_ on
    my machine every night when I am usually asleep. For me this is much
    simpler
    than reading a long thread about how to backup less than all,
    ensuring that
    what I need on the backup tape will not be there when I need it.
    1. with a few key-strokes you allocate one of the 2 panels to the
    bakup-dir; which you can SEE is empty if it's expected to be so,
    or otherwise.
    2. with a few key-strokes you SELECT the *.for files, which you
    can SEE because they are immediately hi-lit, and their number
    and total size is immediately SHWN.
    3. a single key-stroke either moves or copies them to the
    bakup-dir; and you can SEE them appear in the bakup-dir.
    If you need to recursively copy all '*.for' from a whole dir-tree,
    mc can VISUALLY do that too, by first collecting [Panelising]
    all the '*.for' to a 'temp' before you move/copy and SEE them
    arrive in the 'bakup-bowl'.
    I trust you that you can do that visually, but except for a tiny
    number of
    files located where I can see them (e.g., in a single directory), I
    _do not want to see them_. If there were more than about a dozen
    files, I
    certainly do not want to endure the pain of examining all of them to
    see that they are the ones I want, and examining all the rest to ensure
    that none were accidently omitted.
    I want the machine to do it, not me.
    Why I'm so agitated about this non-use of mc, by even long
    time linux users, is that I'm worried that there may be other
    jewels [which could make my life easier] which I'm ignorant of,
    like so many are ignorant of mc .
    For those many who will disagree with me, I suggest that next time
    you put sugar in your coffee-cup, first put on a blindfold and walk
    around the table twice, if you need the challenge of pretending
    to communicate with the little-man-in-the-box.
    Well yes of course, if you are 'moving' thousands of files,
    you don't want to see them. But then you wouldn't be
    asking questions on newsgroups ?
    BTW I've just looked with mc to [eg] move all the *p* files in
    dir-tree /home to <a random dirand a few keys [I don't (want
    to) know what they are - that's the whole point of 'visual']
    shows me 78Mb 251 files. So I could eg. use such tricks
    to collect all *dog* files, and then sort then into *red* , *blue*,
    in case I knew I had files like ?red?dog? , ?dog7blue?
    mc is an example of a good product [NC] which was cloned to
    become even better !
    == Chris Glur.
  • No.1 | | 653 bytes | |

    news@absamail.co.za wrote:

    snip

    BTW I've just looked with mc to [eg] move all the *p* files in
    dir-tree /home to <a random dirand a few keys [I don't (want
    to) know what they are - that's the whole point of 'visual']
    shows me 78Mb 251 files. So I could eg. use such tricks
    to collect all *dog* files, and then sort then into *red* , *blue*,
    in case I knew I had files like ?red?dog? , ?dog7blue?

    mc is an example of a good product [NC] which was cloned to
    become even better !

    Which in turn was a clone of a public domain CP/M program of 25
    years ago. I forget its name then.
  • No.2 | | 947 bytes | |

    2006-01-02, news@absamail.co.za wrote:
    n@absamail.co.za wrote:

    BTW I've just looked with mc to [eg] move all the *p* files in
    dir-tree /home to <a random dirand a few keys

    That's just a few keys at a command prompt:

    find . -name '*p*' -exec mv {} <a random dir+

    [I don't (want to) know what they are - that's the whole point of
    'visual']

    You use a *visual* tool so that you *don't* see?

    shows me 78Mb 251 files. So I could eg. use such tricks to
    collect all *dog* files, and then sort then into *red* , *blue*, in
    case I knew I had files like ?red?dog? , ?dog7blue?

    Again, simple at the command line.

    mc is an example of a good product [NC] which was cloned to
    become even better !

    I find mc clunky, ugly, and more trouble than the command line.
    If I want a *visual* file manager (and I often do), I use Gentoo.
  • No.3 | | 751 bytes | |

    Mon, 2 Jan 2006 10:54:39 -0500, Chris F.A. Johnson
    <cfajohnson@gmail.comwrote:

    I find mc clunky, ugly, and more trouble than the command line.

    I find it indspensible. I use it for file management, most editing,
    etc, etc. Sometimes faster to use than CLI, sometimes not, depends on
    what I'm doing, but then I'm really used to it. You're no doubt more
    acclimated to the CLI for ordinary file tasks than I am.

    But MC is certainly not ugly running in a transparent color aterm with a
    customized color scheme. Default colors - yeah, not real attractive,
    but functionally effective.

    If I want a *visual* file manager (and I often do), I use Gentoo.

    ? Never impresseed me much, just ok.

Re: mc = Killer Ap !


max 4000 letters.
Your nickname that display:
In order to stop the spam: 5 + 4 =
QUESTION ON "Unix/Linux"

EMSDN.COM