Doubt ls-l|more

Doubt ls-l|more

Post by Dath » Tue, 22 Apr 2003 16:36:26



Hi,
I have one new doubt of Unix.
We have the combination of commands called ls -l|more.Can somebody
explain working of this comand. My doubt is, let me list down the
probable steps.
1. Shell will fork one child to execute abve command.
2. Ls executes which will list the directory contents.
3. LS actually has to feed the data into a pipe so that more can use
it.
4. more will read from the pipe and display on Screen.
5. That looks like end of story.
Now my doubt is in step number 3, how 'ls' will feed the data into the
pipe. How 'more' gets info on which is the pipe it has to read.
Can u clear the doubt.

-datha
 
 
 

Doubt ls-l|more

Post by Iain D Broadfoo » Tue, 22 Apr 2003 20:35:29


Datha said something about Doubt ls-l|more:

Quote:> Hi,
> I have one new doubt of Unix.
> We have the combination of commands called ls -l|more.Can somebody
> explain working of this comand. My doubt is, let me list down the
> probable steps.
> 1. Shell will fork one child to execute abve command.
> 2. Ls executes which will list the directory contents.
> 3. LS actually has to feed the data into a pipe so that more can use
> it.
> 4. more will read from the pipe and display on Screen.
> 5. That looks like end of story.
> Now my doubt is in step number 3, how 'ls' will feed the data into the
> pipe. How 'more' gets info on which is the pipe it has to read.

ls puts data on stdout, more reads data from stdin, '|' connects the
two.

man {bash,sh,csh,tcsh,zsh} for more info.

iain

--
wh33, y1p33 3tc.

"If sharing a thing in no way diminishes it, it is not rightly owned if it is
not shared." -St. Augustine

 
 
 

Doubt ls-l|more

Post by Jens.Toerr.. » Tue, 22 Apr 2003 20:52:34



> I have one new doubt of Unix.
> We have the combination of commands called ls -l|more.Can somebody
> explain working of this comand. My doubt is, let me list down the
> probable steps.
> 1. Shell will fork one child to execute abve command.

No, the shell will fork *two* processes for the above command,
one running 'ls' and another one for running 'more'.

Quote:> 2. Ls executes which will list the directory contents.
> 3. LS actually has to feed the data into a pipe so that more can use
> it.

No, it doesn't. The process running 'ls' just writes to its
standard output without needing to know where its really
writing to. The trick is that the shell starts the process,
which then executes 'ls', with its standard output redirected
to a pipe. So, the shell basically does the following:

shell: create pipe
shell: fork

After the fork you now have two processes. The parent process
is the shell, while in the child process now it happens:

child 1: redirect standard output to the pipe
child 1: exec() 'ls -l'

exec() is one of a family of functions that replaces the code of
the shell with the 'ls' program. So 'ls' gets run, automatically
sending its output to the pipe. The function for redirecting
standard output to the pipe is dup(2) or dup2(2).

Quote:> 4. more will read from the pipe and display on Screen.

For 'more' the shell starts another process, this time with its
standard input redirected to the same pipe the process running
'ls' is writing to:

shell:  fork

child 2: redirect standard input to the pipe
child 2: exec() 'more'

So now whatever 'ls' writes goes to the pipe, and whatever 'more'
reads comes from the pipe.

Quote:> 5. That looks like end of story.

Mostly. There's some additional tickery in that 'ls' is able to
figure out from within itself if it's writing to a terminal or
to a file or pipe and may change its output format accordingly
(e.g. by printing out one file per line instead of several beside
each other etc.).
                                     Regards, Jens
--
      _  _____  _____

  _  | |  | |    | |
 | |_| |  | |    | |          http://www.physik.fu-berlin.de/~toerring
  \___/ens|_|homs|_|oerring
 
 
 

Doubt ls-l|more

Post by Dath » Wed, 23 Apr 2003 03:12:28



> Hi,
> I have one new doubt of Unix.
> We have the combination of commands called ls -l|more.Can somebody
> explain working of this comand. My doubt is, let me list down the
> probable steps.
> 1. Shell will fork one child to execute abve command.
> 2. Ls executes which will list the directory contents.
> 3. LS actually has to feed the data into a pipe so that more can use
> it.
> 4. more will read from the pipe and display on Screen.
> 5. That looks like end of story.
> Now my doubt is in step number 3, how 'ls' will feed the data into the
> pipe. How 'more' gets info on which is the pipe it has to read.
> Can u clear the doubt.

> -datha

Thank U for all the reply. Thanx a lot.
-datha
 
 
 

Doubt ls-l|more

Post by Sean P. Bur » Thu, 24 Apr 2003 04:02:39




> > I have one new doubt of Unix.
> > We have the combination of commands called ls -l|more.Can somebody
> > explain working of this comand. My doubt is, let me list down the
> > probable steps.
> > 1. Shell will fork one child to execute abve command.

> No, the shell will fork *two* processes for the above command,
> one running 'ls' and another one for running 'more'.

> > 2. Ls executes which will list the directory contents.
> > 3. LS actually has to feed the data into a pipe so that more can use
> > it.

> No, it doesn't. The process running 'ls' just writes to its
> standard output without needing to know where its really
> writing to. The trick is that the shell starts the process,
> which then executes 'ls', with its standard output redirected
> to a pipe. So, the shell basically does the following:

> shell: create pipe
> shell: fork

> After the fork you now have two processes. The parent process
> is the shell, while in the child process now it happens:

> child 1: redirect standard output to the pipe
> child 1: exec() 'ls -l'

> exec() is one of a family of functions that replaces the code of
> the shell with the 'ls' program. So 'ls' gets run, automatically
> sending its output to the pipe. The function for redirecting
> standard output to the pipe is dup(2) or dup2(2).

> > 4. more will read from the pipe and display on Screen.

> For 'more' the shell starts another process, this time with its
> standard input redirected to the same pipe the process running
> 'ls' is writing to:

> shell:  fork

> child 2: redirect standard input to the pipe
> child 2: exec() 'more'

> So now whatever 'ls' writes goes to the pipe, and whatever 'more'
> reads comes from the pipe.

> > 5. That looks like end of story.

> Mostly. There's some additional tickery in that 'ls' is able to
> figure out from within itself if it's writing to a terminal or
> to a file or pipe and may change its output format accordingly
> (e.g. by printing out one file per line instead of several beside
> each other etc.).
>                                      Regards, Jens
> --
>       _  _____  _____

>   _  | |  | |    | |
>  | |_| |  | |    | |          http://www.physik.fu-berlin.de/~toerring
>   \___/ens|_|homs|_|oerring

I would only add that the 'redirect' part is accomplished
by using close() and dup2() (which may not be obvious).
Look at the source for popen() in Linux or BSD to see
how it's done.

-SEan

 
 
 

1. GFP_KERNEL doubt!! <was Tasklet doubt!>

  Hello,

The problem of allocating more than 2.5 MB was actually more or less
related to the physical memory left in the kernel.
But I moved the task which allocated the memory from the tasklet to the
keventd and used kmalloc (GFP_KERNEL).

The first time I ran my module, it failed at the same 2.5 MB limit.
I restarted the system and tried it again, and I was able to allocate 5
MB successfully.
I restarted the system and ran "free".
The report is as follows:
             total       used       free     shared    buffers     cached
Mem:         62264      30624      31640          0       8072      16096
-/+ buffers/cache:       6456      55808
Swap:       192772          0     192772

Then I ran gcc and compiled my code and then for the "free" report again.
The report is as follows:
             total       used       free     shared    buffers     cached
Mem:         62264      45320      16944          0       9256      28384
-/+ buffers/cache:       7680      54584
Swap:       192772          0     192772

I was able to notice that the physical memory had gone down though "gcc"
had completed.
The time I ran my application, I had about 2.5M physical memory left, so
I was able to allocate 2.5M.

What is happening ? What is the buffers/cache column and is there any
way I could force the kernel to release the cached memory back to free
physical ?
Is there any way I can allocate more than what is left free from the
physical memory ?

Any pointers or suggestions would be very helpful.

Thank you.
Regards,
Sriram

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. Linux gateway windows network neighborhood

3. /usr/bin/ls /usr/ucb/ls /usr/local/bin/ls

4. DOSEMU modules

5. FTP keeps using /usr/bin/ls and not ~/ftp/bin/ls

6. PCMCIA Plug and Pray

7. ls -a and ls *

8. smit.log and smit.script files

9. Help: can't ls-l /

10. ls color highlighting as in the ls command in the slackware distribution

11. Making a boot disk with LS-120 (was Re: LS-120 clicking)

12. Need static ls or ls source...

13. ls > ls.txt 2>&1