Actually after trying it, I found that devmon (from udevil) is very fast. It works like this (docs here):


If there is an /etc/fstab entry for the device (which should really be using the UUID) then devmon will respect that and mount the device there. I'm not trying to put down your script here SCerovec, but just correcting the misconception that udevil is not fast/requires more typing.

1 members found this post helpful.

The option of drgibbon at ~/.mrc is philosophically sound under existing unix/linux practices, in fact even giant programs employ that policy, a slacker can do that manually anytime.

Although, to me personally my linux common-sense shall expect something like /etc/mrc --because, modesty aside, slackware practitioners unconsciously develop a peculiar common hive attitude what mother-bee at /etc tells to swarms of dumb binaries working unwittingly among processes.

The unspoken hesitance of the author SCerovec at choosing /etc/mrc instead of /etc/m/mrc bespeaks rather a reluctant but genuine "slackeresis" --a computing sickness that can develop in a user through constant use of Slackware, or a mental tendency to know the proper place for everything, due to slackware's sound implementation of what an operating system should be; often, this sickness can go worse seeing how your system is boringly stable fast and beautiful, though this chronic discomfort can get abated easily by a cup of coffee. !

Pardon my joke. I'm just getting bored of my Slackware 12 that never breaks for almost a decade now in spite hardwork. I may not say I am thankful to His Excellency Pat Volkerding, but certainly... I am deeply grateful .

Salud!

m.m.

1 members found this post helpful.

I apologize sir.
I didn't state it clear:
no human is to measure up to computer processing a stream.
I meant acceleration by less typing.
I merely type m
and go on with business as usual.
That scratched my itch.
and by means of a simple script - no functionality added, no review time needed, just deploy and use away.
I don't underestimate udevil not a tiny bit. Moreover where it there when i had my issues re:[u[mount]], i've never come up with said m in the first place.

But now we have eduev in place:

Want me show You how this udevil is obsolete, or at least an overkill?

I could make eudev rules that do it all way up to the mount of the plugged-in storage.
Even have it fsck-ed if needs be done.

For umount: I could decide to have them mounted "sync", or have an action to warn in-front of an unplug.

Not to mention the message bus and it's inhuman .xml streams of obfuscations that can be tamed by means of wrappers and forced into obedience without X running.

My point:
whatever the out of box OS can do, do using least amount of additional cruft.

Heck, maybe there is a way to do m without a script even?

Aren't we Slackers all hackers or not? O.o

So, kindest thanks, dear mrgibbon, no offense taken nor any intended.

I merely reflect my personal opinion, however wrong, out of my personal experience, however limited and non aplicable to reality.

Also i highly value Your effort to bring forward the fact and possible other solutions. This is always welcome and should be encouraged among our community - otherwise we wouldn't have htop in the box yet, for instance.

here:
_
V <---have a medal for trying
*

me, I'll slack on with m and co. (...have more scripts in the chest )

Well I could use one of following places:
But no thanks, i think i will explore more obscure (hackish) ways to run my m now,
and deploy it elsewhere...
i will report back

Does no one else use autofs(5) automount(8) anymore?


Anyway, whether people like/use your script or not, Kudos for actually getting off your arse and creating something. It's more than many people ever do.

2 members found this post helpful.

I understand, and I write scripts to do various things too (which I think this is a great thing). But it is also true that you could use udevil with less effort than m at the moment (that includes typing and configuration). Mounting with devmon requires no typing and no prior mountpoint configuration (obviously devmon should load automatically with the environment), it makes use of any present fstab entries, and if you alias 'devmon --unmount-recent' to a single character, then you have a system that works across all removable devices and uses only 1 character. I just want to make sure that this is recognized, in case people read this thread and think that udevil "takes more typing work" when it really doesn't. But still, thanks for sharing your work, some might prefer your more straightforward approach.

2 members found this post helpful.

Apparently no? :/

Mah, at moments I feel like an keyboard monkey :0}

I knew You would come out with that

Yes udevil is a nice add-on, and quite powerful and polished at the edges.
But it's developers didn't have the wits that "we the users" want just to type less, and not to know more.
So that alias comes as Your (excellent) add-on to an (IMHO) late_to_game "automount just got better" project.


IMO the "mount the latest device" should be an intrinsic property of an OS, not something that should be added to it?

As well as mount toggling by a simple (short?) command.

I know I have been harping on about udevil, but some people have already expressed interest in your script, so it's already been appreciated at least by a few Your m is clearly a valid way of mounting stuff, I just think we should be informed about what other ways there might be before writing them off. Keep on hacking

Relax, dude, it's Slackware:
We each have the same OS and each our own preferences, it's okay to recommend Your own preferences.
No harm in that.
And I think I even like Your way (non intrusive).
I hope You get it clear is, not to expect anyone accept the offered preferences;
That's the key:
Offer and leave be, as in freedom.

Other than that, one is simply doing it wrong

Oh, and I will (keep on hacking)

Sure, I only looked into it because of this thread though (and udevil was mentioned early on). More out of interest really (and possibly procrastination ;P). Actually everything I mount regularly is set up in scripts, and for the rest I am usually dealing with a graphical file manager (or zsh's awesome history substring search, which was stolen from fish I believe).

learning zsh is on my (pretty long now) TODO list

My 2 cents about this... (and I likely won't use it, not because it isn't useful, but because about the only time I use a thumbdrive, I am already in KDE and just use dolphin's popup to mount it -- so this is just my humble opinion from the outside looking in)

If you would like to have it be a Slackware package, you shouldn't put the binary in ~/bin/, nor should you have the primary config file be ~/.mrc, however, if you plan on having the user just download the script and save it locally (possibly editing their $PATH so ~/bin/ is included), then it would probably be best to just hardcode the config options at the top of the script and allow the user to either pass variables to the script or replace the default values themselves and not support an ~/.mrc file.

If you do want to provide a Slackware package, I feel /etc/mrc makes the most sense with the ability for users to override it by using ~/.mrc.

With you current /etc/rcm (I agree with malekmustaq that it should probably be renamed to mrc to prevent confusion with rc.M), I would also make the more likely edited entries be at the top. Namely, the device and mount point. I would put both of those before the color scheme, because it is less likely someone would edit the color scheme over the device and/or mount point. I would also remove the echo statement and the /bin/sh at the top, as config files generally shouldn't be scripts themselves, just sourced by the script.

As far as new features, it might be nice to support using UUIDs (and not by just using /dev/disk/by-uuid/, although, worst comes to worst, that is still an option), and possibly multiple mount locations based on the device. That would add complexity to the script, so I understand if you'd rather not get into that. I could just see it being beneficial for those who may plug in multiple devices or can have their device points changed (adding/removing a semi-active external harddrive and then trying to plug in a thumbdrive).

Overall, this is a great idea for those whose devices tend to be the same and either are in the CLI frequently or their preferred WM/DE doesn't support automounting (or the user prefers to have that disabled). I hope you don't take my suggestions as criticisms. They are just a few things I saw that might improve your script.

3 members found this post helpful.

@bassmadrigal
all good points, all considered by me too.

I think I would not want it to be a Slackware package (too minor to matter?)

I think i rather make this and few others individual (per user) scripts.

for ~/bin/

and be just downloadable archives as such?

Key point is "easy" and "useful".

Once deployed on a typical Slackware, the home survives quite long (decades?) so why bother?

And my script, being what it is, is quite agnostic to both device management, naming conventions (hda -> sda -> mmc ...) architecture etc, so i can expect it could roll quite a while before becoming obsolete?

I think next release goes ~/bin/

And there will be a collection, as I plan to publish few more tiny utilities down the line.


Kindest thanks for the support.