|
Home > Archive > Unix Shell > October 2005 > implementation of redirection and redirection error handling
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
implementation of redirection and redirection error handling
|
|
| savsavitha2000@gmail.com 2005-10-24, 3:45 pm |
| hi all,
I would like to know how redirection is implemented internally?Is it
implemented using pipes?what would happen when a command like 'ls >
ls.out' this is run ?
I also need information on redirection error handling.If the output of
a command/binary is redirected to a file in a file system that is
full,is it the responsibility of the shell or the binary to do the
error handling and display an appropriate error message(Ex:There is no
space on the device)?
For ex:ls > /tmp/ls.out
when the output of ls is redirected to /tmp/ls.out(where the file
system /tmp is full),should the error handling be done by the shell or
ls?
Any info on this would be appreciated.
| |
| Bill Marcum 2005-10-24, 3:45 pm |
| On 14 Oct 2005 05:42:20 -0700, savsavitha2000@gmail.com
<savsavitha2000@gmail.com> wrote:
> hi all,
>
> I would like to know how redirection is implemented internally?Is it
> implemented using pipes?what would happen when a command like 'ls >
> ls.out' this is run ?
>
The shell normally opens three file handles (stdin, stdout, stderr)
before launching a program. By default, in an interactive shell,
/dev/tty is opened for all three, but that can be changed by
redirection.
> I also need information on redirection error handling.If the output of
> a command/binary is redirected to a file in a file system that is
> full,is it the responsibility of the shell or the binary to do the
> error handling and display an appropriate error message(Ex:There is no
> space on the device)?
>
> For ex:ls > /tmp/ls.out
>
> when the output of ls is redirected to /tmp/ls.out(where the file
> system /tmp is full),should the error handling be done by the shell or
> ls?
If the file cannot be opened, the shell should handle the error. If it
can be opened but not written, ls handles the error. ls does not know
the filename, so the error message would mention "stdout".
--
Avoid the Gates of Hell. Use Linux
-- unknown source
| |
| Barry Margolin 2005-10-24, 3:45 pm |
| In article <1129293740.098153.275350@g43g2000cwa.googlegroups.com>,
savsavitha2000@gmail.com wrote:
> hi all,
>
> I would like to know how redirection is implemented internally?Is it
> implemented using pipes?what would happen when a command like 'ls >
> ls.out' this is run ?
No, pipes are only used when piping, e.g. 'ls | head'. When you
redirect, the shell simply opens the file and connects the command's
stdout to the open file. The code is something like:
outfd = open("ls.out", O_WRONLY | O_CREATE | O_TRUNC, 0666);
if (outfd == -1) {
/* Report error */
} else {
switch (child = fork()) {
0: /* this is child process */
dup2(STDOUT_FILENO, outfd);
close(outfd);
execlp("ls", "ls", (char*)NULL);
break;
-1: /* fork failed */
perror("fork failed");
break;
default: /* this is parent process */
wait(&status);
}
}
}
> I also need information on redirection error handling.If the output of
> a command/binary is redirected to a file in a file system that is
> full,is it the responsibility of the shell or the binary to do the
> error handling and display an appropriate error message(Ex:There is no
> space on the device)?
>
> For ex:ls > /tmp/ls.out
>
> when the output of ls is redirected to /tmp/ls.out(where the file
> system /tmp is full),should the error handling be done by the shell or
> ls?
Even though the filesystem is full, there might be room to create the
filename in the directory, in which case the shell won't get an error
when it creates the file. In that case, the error will occur when the
program tries to write to its stdout, and it should have appropriate
error handling on all its I/O calls.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| savsavitha2000@gmail.com 2005-10-24, 3:45 pm |
| Thanks for those replies.It would be great if you could let me know if
the above fact(that of an application and not the shell handling the
error in the given situation) is documented somewhere(POSIX/Unix
standards or Solaris/AIX/HP-UX documentation).
| |
| Enrique Perez-Terron 2005-10-24, 3:45 pm |
| On Fri, 21 Oct 2005 16:37:11 +0200, <savsavitha2000@gmail.com> wrote:
> Thanks for those replies.It would be great if you could let me know if
> the above fact(that of an application and not the shell handling the
> error in the given situation) is documented somewhere(POSIX/Unix
> standards or Solaris/AIX/HP-UX documentation).
I don't know many details of the docs you mention, but it would surprise
me if the "above fact" is mentioned explicitly. I think this is a
consequence of an architecture, which indeed *is* documented many places.
What I mean is that the information you would like to find in the
docs is spread out over too many places to be practically accessible.
It is probably not described in any standards document that a file system
implementation may be able to create an empty file even if there are no
blocks free in the file system. I can't imagine it is *required* to be
so, but I also can't imagine it is required *not* to be so. The situation
is not much different if the file system has 10 blocks still free when
the file is created, but some other process takes those blocks before
the ls command gets to write anything. The situation is also not different
if ls successfully writes the first few lines of output, but fails when
the output crosses a block boundary.
You will find specified what the shell is supposed to do when a redirection
appears in a command, but everything is written assuming a basic picture of
the computing model where applications do system calls and receive error
codes if it fails for whatever reason.
If the shell creates the file, according to the standard and the redirection,
or opens a preexisting file, and the operating system does not report an
error, the shell will proceed to the next step, forking the "ls" command.
Quite reasonably, the standard does not specify that the shell shall issue
an error message if all the system calls complete with no error status,
if the ls command *is going to fail*.
What the standards can say, is what each component is supposed to do, and how
they shall respond if they receive error statuses from the OS. If the shell
is obligued to open a file, and this fails it cannot go on and start the
ls command, because the ls command is supposed to have an output file open
when it starts. So the shell reports the problem. If the shell sees no
error, starts ls, but ls gets an error status from the OS when it calls
the write() function, ls reports the problem.
-Enrique
|
|
|
|
|