Some time i worked a lot on command line and used USB storage at the same time a lot.
On Slackware both servers and laptops.
I found it tiresome to switch to a GUI to manage mounting and unmounting-ejecting the volume, I needed a tool to manage it for me on CLI

and I made it

it is called m.

Then I wanted to share it to public (GPL v3), and did go to SF and stuff...

Had to call the project just-m, as m was too short

here link, and those who are interested please report back?

Have few other CLI tools too, that I could share here.

Developed for and used on Slackware.

Thanks for that. Saves keystrokes for me what with Parkinsons AND fat fingers. I can type 96 wpm but correcting the spelling reduces the number to somewhere around 15 or so.

Tried it as root and as user and it works well. Type m and <enter>

Hi,
Out of curiosity I tried your "M". It's colorful. Thanks.

I have no problem with mounting and unmounting though, my DE is XFCE4
and it is doing well on GUI, although, while in CLI I should need find
the mounted USB at /run/media/me/volume_recitals.

However, it only works on a Vfat USB. I have formatted the USB
to half Vfat and half ext4 and "m" did not mount the latter.
If you can improve it to mount anything on dedicated folder
there is chance many will use it since the command *m* is so handy on CLI.

Thanks again for the try and congratulations.

m.m.

kind thanks for the appreciation

some (non) obvious tricks for m

to mount other than sdb1
many times: edit the /etc/rcm
once : type
for mounting sdb2 to /mnt/hd
or
the result is left as an exercise for the reader

the /etc/rcm holds the predefined mountpoint and device

Since i long time now have used various setups and "solutions" i found that most of time we deal with the same device although different USB-appliances.

Only rarely we use to copy USB to USB both hot plugged, and even then we gain in copy/paste method instead of direct streaming IMO (backup copy on HD)

So i finally decided i try implement it "right thing" instead of "right way":

lone m is for the by far most cases - so most acceleration
seldom used m <device> is for the few occurrences of exotic partitioning:
for partition-less formatting for instance
or
for logical volumes behind the primary ones

For instance I had two fixed disks and used sdc1 as my default device.

For the aforementioned sdb2 as ext4 i recommend using an alias and a capital letter:

in some of the bash init scripts (.bashrc or .bash_profile) to keep it short?

HTH?

2 members found this post helpful.

You may want to have a look at this first:

https://slackbuilds.org/repository/14.2/system/udevil/
https://ignorantguru.github.io/udevil/
https://github.com/IgnorantGuru/udevil/

Hi, maybe I don't understand, but isn't that what /etc/fstab is for? You can set the UUID and mountpoint (as well as mount options).

I get the impression You miss the spirit of my tool:
udevil is done "right way", all bells and whistles there, but hardly any acceleration?
Alone sudo setup of my tool provides for all written, as it allows all users to do mount without password?
m, OTOH is conceived "right thing", it's a hack, most of time i type in "that", let's see if we can save some keystrokes. But to umount, it gets even worse, what's mounted? Is it temporary or in fstab?
Now I just issue
and get rainbow

Further, I prefer to have all my custom scripts in ~/bin, this one included, and no exteral configs, but to release it I had to comply with packaging :-J

Okay, but how is that quicker than
?
for both mount and umount, ballpen style?

Maybe try it and removepkg if don't like; It wont bite You

I was just wondering why the introduction of /etc/rcm instead of getting the information from /etc/fstab?

I don't have too much need for these things, but it looks like udevil can automount (using the devmon script in daemon mode) and then you could alias "devmon --unmount-recent" (or --unmount-removable) to whatever you like, which might only require typing one character for the whole deal (and wouldn't require any configuration of drives/destinations). But nothing wrong with writing your own script either

@drgibbon: I see

fstab is a system map; his /etc/rcm is a kind of personal diary. I understand his purpose of "m" and he made his point with colors.

I remember I controlled several usb sticks from udev and it was fun creating rules; but adding the action "mount to somewhere" was just something expensive overdoing the purpose of udev. Contrary to the simple rationale of "m" that after syncing the device it is found in dedicated place by the simple "m" with the least expense.

My complain though: /etc/rcm should not have been used, because it will tend to confuse newbies with /etc/rc.d/rc.M. Since the contents of the diary is nothing but personal to "m" (like an *rc to it) the file name would have been named as "mrc" to sound like .bashrc, etc. But anyone can change that anytime so long as you GPLv3 it.

Good luck.

m.m.

2 members found this post helpful.

@malekmustaq:
I might actually consider change to mrc, for I was bashing my head as just m was too short.
maybe even reconsider moving it back to ~/bin/ and have it installed on per user basis in a merged config+script form? :-/

I was just wondering, as I have some USB drives for my system listed in /etc/fstab (with UUID and mountpoint), and that seemed like the same information to me. Although I think it probably makes more sense to avoid manually managing the mountpoints for transient stuff (e.g. have them automount in /run/media), but whatever works

You could store the system-wide config file in /etc/m/mrc (or whatever), and also check for an ~/.mrc override.

True, but an user owned ~/bin/m would be the only point of reference if moved on per-user basis:

1. It's a script, why not edit it then?
2. It's complicated enough that the default has to be determined by user, why add another file to care about?

OTOH:
maybe check on the 1st run and make the file by the m alone?

(here by means of *automagic* we pull the current not mounted (yet dmesg grepped too) storage,
or sdb1 if none found (sane default?)"
therefrom we do the initial 1st run (off the sourced /etc/mrc file)

Of course in FATTY rainbow
what gives?

my vote is for the single "m" in ~/bin/, and no external files (by far MOAR easy to move around), and user editable since sudo takes care of safety, and we just take care of speed (mere wrapper for defaults with as few sanity checks)
We supposed to be Slackers remember?