[7.3] umount says: "umount: /very/long/path (/dev/loop0) is unmounted" ?

McZ · 03-14-2013, 10:36 AM

So I have just finished updating my scripts to build 7.3. Now when I started to build my BLFS packages (also scripted) umount is bugging me with

Code:

umount: /very/long/path (/dev/loop0) is unmounted

even though my script is redirecting umount text:

Code:

umount /very/long/path > /dev/null 2>&1

umount is not bugging me with this text in LFS-7.2. Anyone have any idea why this text appears? or even better how I can remove it.

#root · 03-14-2013, 10:46 AM

Output redirection

The greater-thans (>) in commands like these redirect the program’s output somewhere. In this case, something is being redirected into /dev/null, and something is being redirected into &1.
Standard in, out, and error

There are three standard sources of input and output for a program. Standard input usually comes from the keyboard if it’s an interactive program, or from another program if it’s processing the other program’s output. The program usually prints to standard output, and sometimes prints to standard error. These three file descriptors (you can think of them as “data pipes”) are often called STDIN, STDOUT, and STDERR.

Sometimes they’re not named, they’re numbered! The built-in numberings for them are 0, 1, and 2, in that order. By default, if you don’t name or number one explicitly, you’re talking about STDOUT.

Given that context, you can see the command above is redirecting standard output into /dev/null, which is a place you can dump anything you don’t want (often called the bit-bucket), then redirecting standard error into standard output (you have to put an & in front of the destination when you do this).

McZ · 03-15-2013, 05:34 AM

Quote:

Originally Posted by #root

Output redirection

The greater-thans (>) in commands like these redirect the program’s output somewhere. In this case, something is being redirected into /dev/null, and something is being redirected into &1.
Standard in, out, and error

There are three standard sources of input and output for a program. Standard input usually comes from the keyboard if it’s an interactive program, or from another program if it’s processing the other program’s output. The program usually prints to standard output, and sometimes prints to standard error. These three file descriptors (you can think of them as “data pipes”) are often called STDIN, STDOUT, and STDERR.

Sometimes they’re not named, they’re numbered! The built-in numberings for them are 0, 1, and 2, in that order. By default, if you don’t name or number one explicitly, you’re talking about STDOUT.

Given that context, you can see the command above is redirecting standard output into /dev/null, which is a place you can dump anything you don’t want (often called the bit-bucket), then redirecting standard error into standard output (you have to put an & in front of the destination when you do this).

From what you are saying

Code:

{command} > /dev/null

is redirecting STDOUT to /dev/null, all I see is errors if there are any and if they are printed to STDERR.

And adding 2>&1 will redirect STDERR to STDOUT

Code:

{command} > /dev/null 2>&1

So, then I should se nothing?

if so, why am I getting this output when I'm redirecting to /dev/null?

Code:

umount: /very/long/path (/dev/loop0) is unmounted

#root · 03-24-2013, 02:38 AM

/dev/loop0 indicates the use of a loop back device

Quote:

A Loopback Device is a mechanism used to interpret files as real devices.

so i believe that your /very/long/path has a pointer to this loop back device and maybe the existence of pointer leads to the output

try to redirect the output somewhere else rather tha /dev/null and observe what happens

also you can try to umount the loop0 before you execute your command

visit following links
link1
link2

Keith Hedger · 03-24-2013, 01:29 PM

What is the exact command you are using? I can't reproduce this error, it may be a kernel error message for some reason some of which are not easy to redirect.
The form

Code:

SOMECOMMAND >/dev/null 2>&1

is correct although you can use a short cut in newer versions of bash like so

Code:

SOMECOMMAND &>/dev/null

Which redirect BOTH stdin and stderr