I am wondering if I can use if...fi to test if something is already mounted on a particular directory, so that my script can avoid mounting the multiple Samba shares on a single directory. Currently my script is mounting the same shares multiple times, and that can't be good.

Thanks in advance,

Not sure if this is exactly what you wanted. This script assumes that you pass the directory name to be checked as the first parameter.

Look at my post more carefully.
>I am wondering if I can use if...fi to test if something is already mounted on a >particular directory

The purpose is not to double mount, triple mount, or more by checking to see if a SambaFS share is already mounted on the directory or not before using the mount command.

What happened is that I made a fstab entry that was user mountable ( noauto ) and then put the mount command in the .bashrc file. However, with this setup the .bashrc file executes everytime a open up a terminal window, and almost always have 3 of these opened at a time. So, with 3 terminal windows open, a mount command will show the duplicate mounts for the directory/mount pairs that are affected by the bashrc script.

So, in short, I want to make sure the script only mounts something on the folder once, and afterwards if will check if the share is already mounted and not execute a mount command if it sees there is already something mounted on the directory.

That is exactly what my script does. Here is an example of my mount points and how the script executes:
You can see the directories /usr and /share already have filesystems mounted on them. The script reports that it is already a mount point. The directory /var is on the / filesystem and does not have a filesystem mounted. The script reports 'mount away', so nothing is already mounted on /var.

Here's another solution where the results of cat are piped through grep and the return value is checked.

Alert! Useless Use Of Cat!

Also you should specify whitespace or an anchor around the pattern you are looking for; otherwise, longer strings will match your shorter pattern. For example, what if you wanted to know if /mnt/USB was mounted and you happen to have /mnt/USB2 mounted? Your pattern would match /mnt/USB2 even if /mnt/USB was not mounted.

POSIX grep will support the '-q' option, so you don't need >/dev/null if you don't care about seeing the match.

Finally, you can combine the 'if' statement and 'grep' into a single expression. You don't need to check the exit code with $? explicitly -- that's what 'if' does! The square brackets return an exit code which is what 'if' is really looking at. The '[' is the name of an actual program. Type 'which [' at the command-line. You should get "/usr/bin/[".

Here is something a little cleaner:
And as a final, final note, if someone were really evil they could created a mount point with a space in the name. That would seem to break the pattern I gave, but luckily Linux escapes funny characters using their octal value. So if you created and mounted a mount point like this: mkdir "/mnt/mymountpoint too" it would show up in /proc/mounts as /mnt/mymountpoint\040too and so, would not match the pattern "[[:space:]]/mnt/mymountpoint[[:space:]]".

--
Noah

Hi,

you could have a look at
This will tell you if a directory is already a mountpoint. The exit status will be zero if /your/mount/dir is already a mountpoint, otherwise non-zero.
Hope this helps.

1 members found this post helpful.

I agree with crts, use mountpoint. Eg

1 members found this post helpful.

I'm sure it sounds great now, but back in 2004 the mountpoint command did not exist. I'm sure there are thousands of posts that can be improved upon on LQ, but I think I'd be more beneficial to focus your new found skills on more recent posts rather than dig up and improve solutions from 6 years ago.

0 members found this post helpful.

Hmm, did not see that this was a resurrected post from six years ago. I really wonder why people take the time to search for such ancient posts and think it is a good idea to give advice on a long dead thread.

What's wrong with adding good information? I appreciated the post - it was exactly what I was looking for.

Perhaps it could have been framed in a different context, like: "These days, the mountpoint command is available ...". Or since not everyone knows the exact moment a command is born and made available to the world, "Maybe mountpoint(8) was not available it 2004, but ...".

Improving this older post seems perfectly okay to me, especially if people have been (and will continue to) use the only hackish solutions that _used_ to be available when a better one is available now.

Perhaps a more open-minded approach to moderation could be used here.

3 members found this post helpful.

I agree wholeheartedly with wallaceg's assertion that improving on a "hack" contained in a post no matter the age is a good thing. Indeed, with the nature of search results, it could be deemed a necessity IMNSHO.

I too found the post regarding mountpoint helpful.

Thanks for any constructive input.

Carl

1 members found this post helpful.

As a 'yet again' Unix/Linux convert with a ~30yr tenuous hit 'n miss Unix affair, I am grateful for seeing the KISS principle used [maybe stepwise refinement sounds better?].
The various posts are extremely informative and a joy to read and [for me at least] ponder over with other tabs open researching out the various syntax items.
The above code is beyond me [but not for long:] and I can easily see the relevance of it's simplicity. EG, I perhaps incorrectly see that the boolean cond will dip out/short-circuit IF device is mounted ELSE mount it.

Wow... for me this is pure elegance. I'm still struggling with the overall *nix paradigm but have done nuff programming to at least see the possible meaning of that line of code...

imho, Improving on any code is great. As long as it is relevant and not malicious in nature nor just 'yet another' hack that actually, does not improve what went before. But yet, pondering over any/all code is brilliant way to learn and coupled with various posts comments, learn to be more critical/analytical (in a +ve way)

Peer review and [constructive/informative] commentary is what [I feel] should get the juices flowing and cause one to get the terminal pane up and start playing!

Just what I'm off to do now... Seriously, I'm so totally at the crawling stage with Bash and all the zillions of other exciting facets of such a rich computing environment that is *nix.

Excuse the ramble - but I honestly enjoy threads like this. So much can be learned.

Cheers

Evolution is welcome.

mountpoint get my job done here !

Thx.

1 members found this post helpful.

Here's a function I've just put together from the above posts:

Then you can just call it with:

of, if you require su rights and are allowed to sudo without password: