Question about using ls
in [Shell]
|
From: Keith Thompson on 18 May 2010 20:46 "Chris F.A. Johnson" <cfajohnson(a)gmail.com> writes: [...] >> On 5??13??, ?U??10??40??, "Chris F.A. Johnson" <cfajohn...(a)gmail.com> wrote: [...] >>> printf "%s\n" moonhkt moonhkt.[0-9]* [...] > > The shell expands the arguments and printf just prints them. > > There is no reason to use ls without any options. (Someone will > probably come up with a case, but generally ls isn't necessary > unless you are using at least one option.) ``ls'' is a lot easier to type than ``printf "%s\n" *''. ls produces multi-column output if stdout is a terminal. If the current directory has a huge number of files, it's possible that using ls might avoid a shell's limitation on the size of a wildcard expansion. (This is probably a weak argument.) -- Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
From: Chris F.A. Johnson on 19 May 2010 06:00 On 2010-05-19, Keith Thompson wrote: > "Chris F.A. Johnson" <cfajohnson(a)gmail.com> writes: > [...] >>> On 5??13??, ?U??10??40??, "Chris F.A. Johnson" <cfajohn...(a)gmail.com> wrote: > [...] >>>> printf "%s\n" moonhkt moonhkt.[0-9]* > [...] >> >> The shell expands the arguments and printf just prints them. >> >> There is no reason to use ls without any options. (Someone will >> probably come up with a case, but generally ls isn't necessary >> unless you are using at least one option.) > > ``ls'' is a lot easier to type than ``printf "%s\n" *''. True. Which is why I have a function, pr1(): pr1() { printf "%s\n" "$@" } > ls produces multi-column output if stdout is a terminal. I have never liked that, but if you do, it could be a reason for using ls. Or my functions pr2, pr3, etc.. > If the current directory has a huge number of files, it's possible that > using ls might avoid a shell's limitation on the size of a wildcard > expansion. (This is probably a weak argument.) Arguments to shell builtins (such as printf) are limited only by available memory, whereas an external command is limited by the OS. "ls <pattern>" will fail long before "pr1 <pattern>". -- Chris F.A. Johnson, author <http://shell.cfajohnson.com/> =================================================================== Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress) Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress) ===== My code in this post, if any, assumes the POSIX locale ===== ===== and is released under the GNU General Public Licence =====
From: Seebs on 19 May 2010 08:37 On 2010-05-19, Chris F.A. Johnson <cfajohnson(a)gmail.com> wrote: >> If the current directory has a huge number of files, it's possible that >> using ls might avoid a shell's limitation on the size of a wildcard >> expansion. (This is probably a weak argument.) > Arguments to shell builtins (such as printf) are limited only by > available memory, whereas an external command is limited by the OS. Is that always true? I seem to recall having seen a sufficiently long echo command fail. Although come to think of it, that may have been a sufficiently long echo command created by a GNU make expansion. > "ls <pattern>" will fail long before "pr1 <pattern>". Probably true. However, I at least sometimes use shells in which printf isn't built-in, at which point, there are directories for which "pr1 *" will fail, but "ls" won't. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Keith Thompson on 19 May 2010 14:02 "Chris F.A. Johnson" <cfajohnson(a)gmail.com> writes: > On 2010-05-19, Keith Thompson wrote: >> "Chris F.A. Johnson" <cfajohnson(a)gmail.com> writes: >> [...] >>>> On 5??13??, ?U??10??40??, "Chris F.A. Johnson" >>>> <cfajohn...(a)gmail.com> wrote: >> [...] >>>>> printf "%s\n" moonhkt moonhkt.[0-9]* >> [...] >>> >>> The shell expands the arguments and printf just prints them. >>> >>> There is no reason to use ls without any options. (Someone will >>> probably come up with a case, but generally ls isn't necessary >>> unless you are using at least one option.) >> >> ``ls'' is a lot easier to type than ``printf "%s\n" *''. > > True. Which is why I have a function, pr1(): > > pr1() > { > printf "%s\n" "$@" > } Is "pr1" easier to type than "ls"? >> ls produces multi-column output if stdout is a terminal. > > I have never liked that, but if you do, it could be a reason for > using ls. Or my functions pr2, pr3, etc.. Or ls. >> If the current directory has a huge number of files, it's possible that >> using ls might avoid a shell's limitation on the size of a wildcard >> expansion. (This is probably a weak argument.) > > Arguments to shell builtins (such as printf) are limited only by > available memory, whereas an external command is limited by the OS. > > "ls <pattern>" will fail long before "pr1 <pattern>". If I type "ls" with no arguments (or with a directory argument), neither is an issue; the only limit would be the ls command's internal memory in which it constructs a list of the files in the current or named directory. Let me guess -- you have a "pr4" function that lists the current directory. 8-)} -- Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
From: moonhkt on 19 May 2010 21:16 On 5æ20æ¥, ä¸å2æ¶02å, Keith Thompson <ks...(a)mib.org> wrote: > "Chris F.A. Johnson" <cfajohn...(a)gmail.com> writes: > > > > > > > On 2010-05-19, Keith Thompson wrote: > >> "Chris F.A. Johnson" <cfajohn...(a)gmail.com> writes: > >> [...] > >>>> On 5??13??, ?U??10??40??, "Chris F.A. Johnson" > >>>> <cfajohn...(a)gmail.com> wrote: > >> [...] > >>>>> printf "%s\n" moonhkt moonhkt.[0-9]* > >> [...] > > >>>   The shell expands the arguments and printf just prints them. > > >>>   There is no reason to use ls without any options. (Someone will > >>>   probably come up with a case, but generally ls isn't necessary > >>>   unless you are using at least one option.) > > >> ``ls'' is a lot easier to type than ``printf "%s\n" *''. > > >   True. Which is why I have a function, pr1(): > > > pr1() > > { > >  printf "%s\n" "$@" > > } > > Is "pr1" easier to type than "ls"? > > >> ls produces multi-column output if stdout is a terminal.     > > >   I have never liked that, but if you do, it could be a reason for > >   using ls. Or my functions pr2, pr3, etc.. > > Or ls. > > >> If the current directory has a huge number of files, it's possible that > >> using ls might avoid a shell's limitation on the size of a wildcard > >> expansion.  (This is probably a weak argument.) > > >   Arguments to shell builtins (such as printf) are limited only by > >   available memory, whereas an external command is limited by the OS. > > >   "ls <pattern>" will fail long before "pr1 <pattern>". > > If I type "ls" with no arguments (or with a directory argument), > neither is an issue; the only limit would be the ls command's > internal memory in which it constructs a list of the files in the > current or named directory. > > Let me guess -- you have a "pr4" function that lists the current > directory.  8-)} > > -- > Keith Thompson (The_Other_Keith) ks...(a)mib.org  <http://www.ghoti.net/~kst> > Nokia > "We must do something.  This is something.  Therefore, we must do this." >   -- Antony Jay and Jonathan Lynn, "Yes Minister"- éè被å¼ç¨æå - > > - æ¾ç¤ºå¼ç¨çæå - Tested on AIX OK for me. Personal , I will using ls $ ls -1 | egrep "moonhkt(\.[0-9]{8,8})?$" moonhkt moonhkt.20100405 moonhkt.20100406 Make a small function $ function lsb { ls -1 | egrep "$1(\.[0-9]{8,8})?$"; } $ lsb moonhkt.ksh moonhkt.ksh moonhkt.ksh.20100406
First
|
Prev
|
Pages: 1 2 3 Prev: How to pass OPTION? Next: Coloring stdin, stdout, stderr differently |