Bash globbing files only?

[Daniel Qarras]

Hi all,

with Bash one can list directories (excluding dot dirs) like this:

ls [^.]*/

How can I list files instead of directories with Bash? I thought this
would be trivial but I can't find a solution anywhere.

Thanks.




 
____________________________________________________________________________________
It's here! Your new message!  
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/

[Jacques B.]

On 1/28/07, Daniel Qarras <dqarras(a)yahoo.com&gt; wrote:
>  Hi all,
>
>  with Bash one can list directories (excluding dot dirs) like this:
>
>  ls [^.]*/
>
>  How can I list files instead of directories with Bash? I thought this
>  would be trivial but I can't find a solution anywhere.
>
>  Thanks.
>  
I'm not on my Linux partition so I'm going by memory here, but something
like:

ls -lAR / | grep -v "^d"

That will list Almost all files (exclude . and ..), Recursive, long
format, then exclude anything that is a directory (as those have the d
in front of the permissions).

Jacques B.

[Daniel Qarras]

Hi!

--- "Jacques B." <jjrboucher(a)gmail.com&gt; wrote:

>  On 1/28/07, Daniel Qarras <dqarras(a)yahoo.com&gt; wrote:
>  > Hi all,
>  >
>  > with Bash one can list directories (excluding dot dirs) like this:
>  >
>  > ls [^.]*/
>  >
>  > How can I list files instead of directories with Bash? I thought
>  this
>  > would be trivial but I can't find a solution anywhere.
>  >
>  > Thanks.
>  >
>  I'm not on my Linux partition so I'm going by memory here, but
>  something like:
>  
>  ls -lAR / | grep -v "^d"
>  
>  That will list Almost all files (exclude . and ..), Recursive, long
>  format, then exclude anything that is a directory (as those have the
>  d in front of the permissions). 
Yep, that would work, but I guess my question was a bit poorly
formulated. I am writing a bash script that has:

dirs=[^.]*/

and I'd like to have "files=..." without using find or other external
commands if at all possible.

Thanks.



 
____________________________________________________________________________________
TV dinner still cooling? 
Check out "Tonight's Picks" on Yahoo! TV.
http://tv.yahoo.com/

[Jacques B.]

>  Yep, that would work, but I guess my question was a bit poorly
>  formulated. I am writing a bash script that has:
>
>  dirs=[^.]*/
>
>  and I'd like to have "files=..." without using find or other external
>  commands if at all possible.
>
>  Thanks.
>  
Actually that last one wasn't ideal.  A better solution would be
ls -lAR / | grep "^-"
This would give you files, not symbolic links, not directories, not
block devices, not character devices.

I can't find any way to do it with ls alone.

Of course the best way is with the find command, being

find / -type f

which will not only give you the file names, but with their complete
path.  If you want the files listed in long format, then use

find / -type f -ls

By the way the syntax you have to list directories does not work for
me.  It yields the same results as if I did ls *, which lists all
files in the current directory, and files in directories contained in
the current directory (in lieu of listing the directory name).

Any reason why you'd rather use ls instead of find?

Thanks,

Jacques

[Daniel Qarras]

Hi!

>  > Yep, that would work, but I guess my question was a bit poorly
>  > formulated. I am writing a bash script that has:
>  >
>  > dirs=[^.]*/
>  >
>  > and I'd like to have "files=..." without using find or other
>  external
>  > commands if at all possible.
>  >
>  > Thanks.
>  >
>  
>  Of course the best way is with the find command, being
>  
>  find / -type f
>  
>  Any reason why you'd rather use ls instead of find? 
I want just the files from the current directory, not from any subdir.
And I'd prefer some bash globbing if possible for performance/elegancy
reasons :)

Thanks.




 
____________________________________________________________________________________
Need a quick answer? Get one in minutes from people who know.
Ask your question on www.Answers.yahoo.com

[Les Mikesell]

Daniel Qarras wrote:
>  Hi!
>  
> >> Yep, that would work, but I guess my question was a bit poorly
> >> formulated. I am writing a bash script that has:
> >>
> >> dirs=[^.]*/
> >>
> >> and I'd like to have "files=..." without using find or other
> > external
> >> commands if at all possible.
> >>
> >> Thanks.
> >>
> > Of course the best way is with the find command, being
> >
> > find / -type f
> >
> > Any reason why you'd rather use ls instead of find?
>  
>  I want just the files from the current directory, not from any subdir.
>  And I'd prefer some bash globbing if possible for performance/elegancy
>  reasons :) 
Find has more options than you want to know about:

find . -maxdepth 1 -type f -name 'pattern'

Don't forget to quote 'pattern' so the shell won't expand it.

Or you could do something like:

ls -ld pattern |sed -e '/^d/d' -e 's/.* //'
(remove the lines starting with d and all the stuff before the name).

The only way to do it without an external command would be to expand the 
    list in the shell and cycle though the list eliminating the 
directories with a [ -d $VAR ] test.  See 'man test' for the options, 
but it really is a shell built-in.

-- 
   Les Mikesell
   lesmikesell(a)gmail.com

[James Wilkinson]

Daniel Qarras wrote:
>  I want just the files from the current directory, not from any
> subdir.
>  And I'd prefer some bash globbing if possible for performance/elegancy
>  reasons :) 
Les Mikesell wrote:
>  The only way to do it without an external command would be to expand
>  the list in the shell and cycle though the list eliminating the
>  directories with a [ -d $VAR ] test. See 'man test' for the options,
>  but it really is a shell built-in. 
That won't work reliably, either -- directories can contain more things
than plain files or subdirectories. There could be symbolic links,
character or block device nodes, named pipes or sockets.

Daniel should probably briefly consider what he wants to do with any of
these, and program around them. (I suspect "following symbolic links and
ignoring the rest" may be a good heuristic".)

Hope this helps,

James.

-- 
E-mail:     james@ | A wood-pigeon would, If a wood-pigeon could,
aprilcottage.co.uk | But a wood-pigeon can't, So it won't.
                   | A wood-pigeon could, If a wood-pigeon would,
                   | But a wood-pigeon doesn't want to. So it doesn't.

[Jacques B.]

On 1/29/07, James Wilkinson <fedora(a)aprilcottage.co.uk&gt; wrote:
>  Daniel Qarras wrote:
>  > I want just the files from the current directory, not from any subdir.
>  > And I'd prefer some bash globbing if possible for performance/elegancy
>  > reasons :)
>  
The closest I could come up with was using
ls -Ap -I "pattern"

That caused directories to have / at the end of them. So I figured I
could use -I to ignore any filename ending with /.  However after a
few unsuccessfull variations I realized that the / is only displayed
at the end of directories therefore not part of the name. Which means
you cannot use a pattern to eliminate names ending in / (because the
name doesn't end with /, rather / is simply displayed after a
directory name).  Piping to grep would do it of course.

The find command with maxdepth and for type f is your best bet in my opinion.

If you come up with a way to do it from within ls I'd be interested in it.

Now lsattr comes close as well in that it lists files, but also
symbolic links to a directory.  But that produces the attributes along
with the file names.

Like John, I can see no way on how to do it with ls alone from within
bash. Clearly John has a solution for you using another shell so you
could call upon that shell interpreter.  But I don't see zsh on my
default FC6 install.

Jacques B.

Jacques B.

[John Kodis]

On Sun, Jan 28, 2007 at 12:12:11PM -0800, Daniel Qarras wrote:
>  Hi all,
>  
>  with Bash one can list directories (excluding dot dirs) like this:
>  
>  ls [^.]*/
>  
>  How can I list files instead of directories with Bash? I thought this
>  would be trivial but I can't find a solution anywhere. 
I don't think that it can be done with bash, but if you don't mind
switching to zsh -- another extended version of the Bourne shell -- it
does become trivial:

    ~% ls *(.)  # list only plain files
    ~% ls *(/)  # list only directories
    ~% ls *(*)  # list only executable files

-- John Kodis.

[Daniel Qarras]

>  > with Bash one can list directories (excluding dot dirs) like
> this:
>  > 
>  > ls [^.]*/
>  > 
>  > How can I list files instead of directories with Bash? I thought
>  this
>  > would be trivial but I can't find a solution anywhere.
>  
>  I don't think that it can be done with bash, but if you don't mind
>  switching to zsh -- another extended version of the Bourne shell --
>  it does become trivial:
>  
>      ~% ls *(.)  # list only plain files
>      ~% ls *(/)  # list only directories
>      ~% ls *(*)  # list only executable files 
Yes, I am painfully aware of the power of zsh :) But in this case I
need to do my script with bash and it seems that although globbing for
directories is trivial ( */ ) there is no similar pattern to match
files. Oh, well, I guess I'll need to waste some CPU cycles and launch
find everytime I need to know file names in the current directory.

Thanks.




 
____________________________________________________________________________________
Sucker-punch spam with award-winning protection. 
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html

[Jacques B.]

>  Yes, I am painfully aware of the power of zsh :) But in this case I
>  need to do my script with bash and it seems that although globbing for
>  directories is trivial ( */ ) there is no similar pattern to match
>  files. 
I don't know if it's just me, but I tried your syntax to list
directories and that doesn't work for me.
You use:  $ ls [^.]*/
correct?
All that does on my system is list all files, including files in any
subfolders within the current directory. Basically seems to do the
exact same as if I do: $ ls *

Jacques B.

[Daniel Qarras]

Hi!

--- "Jacques B." <jjrboucher(a)gmail.com&gt; wrote:

>  I don't know if it's just me, but I tried your syntax to
> list
>  directories and that doesn't work for me.
>  You use:  $ ls [^.]*/
>  correct?
>  All that does on my system is list all files, including files in any
>  subfolders within the current directory. Basically seems to do the
>  exact same as if I do: $ ls * 
It works for me both on FC6 (bash3) and on Debian Sarge (bash2).
Perhaps there is something different in our inputrc/bashrc.

Thanks.




 
____________________________________________________________________________________
Sucker-punch spam with award-winning protection. 
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html

[Cameron Simpson]

On 29Jan2007 13:57, Jacques B. <jjrboucher(a)gmail.com&gt; wrote:
| >Yes, I am painfully aware of the power of zsh :) But in this case I
| >need to do my script with bash and it seems that although globbing for
| >directories is trivial ( */ ) there is no similar pattern to match
| >files.
| 
| I don't know if it's just me, but I tried your syntax to list
| directories and that doesn't work for me.
| You use:  $ ls [^.]*/
| correct?
| All that does on my system is list all files, including files in any
| subfolders within the current directory. Basically seems to do the
| exact same as if I do: $ ls *

Got an alias for "ls"? Try:

  unalias ls
  ls -d */

The -d says don't treat directories specially (normally ls lists
directory _contents_ if a directory is named).
-- 
Cameron Simpson <cs(a)zip.com.au&gt; DoD#743
http://www.cskk.ezoshosting.com/cs/

C'mon. Take the plunge. By the time you go through rehab the first time,
you'll be surrounded by the most interesting people, and if it takes years
off of your life, don't sweat it. They'll be the last ones anyway.
        - Vinnie Jordan, alt.peeves

[Jacques B.]

>  Got an alias for "ls"? Try:
>
>    unalias ls
>    ls -d */
>
>  The -d says don't treat directories specially (normally ls lists
>  directory _contents_ if a directory is named). 
I do have an alias for ls, but it's simply to add color.  I did the
unalias and get the same results.  Now with the one you have listed
here, I do get the directories.  Even when I source my .bashrc back to
get the alias back, it still works as expected.  So the alias is not
affecting my ls beyond adding color.

Is the command $ls [^.]*/
working as expected for you, listing only directories in your current directory?

I'm fairly comfortable with the basics of bash and some intermediate
bash but I hadn't played with globbing much.  In reading up on it I'm
left with the impression that the command above would list all files
not starting with a period ([^.]), then the wildcard * (so could be
anything at all), followed by the / (which doesn't seem to do
anything).

Even if it did work, would it not exclude any directory starting with
a period?  But that aside, does it work (or not work) for anyone else?

I have

GNU bash, version 3.1.17(1)-release (i686-redhat-linux-gnu)

Thanks,

Jacques

[Cameron Simpson]

On 29Jan2007 18:58, Jacques B. <jjrboucher(a)gmail.com&gt; wrote:
| >Got an alias for "ls"? Try:
| >  unalias ls
| >  ls -d */
| >
| >The -d says don't treat directories specially (normally ls lists
| >directory _contents_ if a directory is named).
| 
| I do have an alias for ls, but it's simply to add color.  I did the
| unalias and get the same results.  Now with the one you have listed
| here, I do get the directories.  Even when I source my .bashrc back to
| get the alias back, it still works as expected.  So the alias is not
| affecting my ls beyond adding color.
| 
| Is the command $ls [^.]*/
| working as expected for you, listing only directories in your current 
| directory?

Yep, in both zsh and bash. BTW, what is the "[^.]" supposed to achieve?
A plain "*" should act the same, I'd expect.

Try this:

  set -x
  ls [^.]*/
  ls -d [^.]*/
  ls -d */

It would be interesting to see what the differences are, if any.

You could whack a ">/dev/null" onto the end of the ls commands
so the "set -x" tracing is easy to see.

| I'm fairly comfortable with the basics of bash and some intermediate
| bash but I hadn't played with globbing much.  In reading up on it I'm
| left with the impression that the command above would list all files
| not starting with a period ([^.]), then the wildcard * (so could be
| anything at all),

Yes, but plain "*" is supposed to not match things beginning with "."
anyway.

| followed by the / (which doesn't seem to do
| anything).

Yes it does - it forces a path traversal. You can do that with a
directory, but not a file (nothing to transverse "into").

| Even if it did work, would it not exclude any directory starting with
| a period?

Yes. I suspect it's a mistake from people trying to avoid "." and
"..".

| But that aside, does it work (or not work) for anyone else?
| 
| I have
| GNU bash, version 3.1.17(1)-release (i686-redhat-linux-gnu)

Me too.
-- 
Cameron Simpson <cs(a)zip.com.au&gt; DoD#743
http://www.cskk.ezoshosting.com/cs/

A lot of people don't know the difference between a violin and a viola, so
I'll tell you.  A viola burns longer.   - Victor Borge

[Jacques B.]

>  Try this:
>
>    set -x
>    ls [^.]*/
>    ls -d [^.]*/
>    ls -d */
>
>  It would be interesting to see what the differences are, if any. 
Thanks for the tip & additional info.  The results of the above after
doing unalias ls and set -x:

(directory names neutered slightly to protect the youngs)

ls [^.]*/
+ ls 'My son'\''s Passion/' Desktop/ download/ 'Final
Material/'
ftools/ images/ 'Linux Forensic Documents/' LPIC/ 'Other son -
Profession/' Photos/ PicasaDocuments/ Presentations/ scripts/ thumb/

followed by the content of each of the above folders


The other two yield identical results, being:

+ ls -d 'My son'\''s Passion/' Desktop/ download/ 'Final
Material/'
ftools/ images/ 'Linux Forensic Documents/' LPIC/ 'Other son -
Profession/' Photos/ PicasaDocuments/ Presentations/ scripts/ thumb/

followed by the directory names above.

I like that trace feature - lets you see how the globbing gets
expanded.  So we see that the original syntax yields the content of
the directories, whereas as expected the -d only lists the directory
names.

Not to beat a dead horse, but I hate not understanding why something
works (or doesn't work).  Why is it working on yours but not mine?
Are you getting the same trace output for the ls [^.]*/ command, but
without listing the contents of those directories, only the directory
names?

Thanks,

Jacques B.

[Cameron Simpson]

On 29Jan2007 21:29, Jacques B. <jjrboucher(a)gmail.com&gt; wrote:
| >Try this:
| >
| >  set -x
| >  ls [^.]*/
| >  ls -d [^.]*/
| >  ls -d */
| >
| >It would be interesting to see what the differences are, if any.
| 
| Thanks for the tip & additional info.  The results of the above after
| doing unalias ls and set -x:
| 
| (directory names neutered slightly to protect the youngs)
| 
| ls [^.]*/
| + ls 'My son'\''s Passion/' Desktop/ download/ 'Final
Material/'
| ftools/ images/ 'Linux Forensic Documents/' LPIC/ 'Other son -
| Profession/' Photos/ PicasaDocuments/ Presentations/ scripts/ thumb/
| 
| followed by the content of each of the above folders

So, as expected then, yes?

| The other two yield identical results, being:
| 
| + ls -d 'My son'\''s Passion/' Desktop/ download/ 'Final
Material/'
| ftools/ images/ 'Linux Forensic Documents/' LPIC/ 'Other son -
| Profession/' Photos/ PicasaDocuments/ Presentations/ scripts/ thumb/
| 
| followed by the directory names above.

Good, also as expected.

| I like that trace feature - lets you see how the globbing gets
| expanded.  So we see that the original syntax yields the content of
| the directories, whereas as expected the -d only lists the directory
| names.
| Not to beat a dead horse, but I hate not understanding why something
| works (or doesn't work).  Why is it working on yours but not mine?
| Are you getting the same trace output for the ls [^.]*/ command, but
| without listing the contents of those directories, only the directory
| names?

I get what you get. We have established A) that "*/" and "[^.]*/"
are equivalent and B) that -d prevents burrowing into the directories.
We should have added:

  ls */

to the tests above to try all four permutations.

Does it make sense now?
-- 
Cameron Simpson <cs(a)zip.com.au&gt; DoD#743
http://www.cskk.ezoshosting.com/cs/

Kilimanjaro is a pretty tricky climb. Most of it's up, until you reach the
very, very top, and then it tends to slope away rather sharply.

[Jacques B.]

>  So, as expected then, yes? 
Yes, as expected.  But not what I
understood the OP was trying to do.
Unless I'm mistaken, that syntax (ls [^.]*/) was used to assign the
directory names in the current working directory to a variable.
However that is not the output of that command. The output is the
directories and their contents.  Hence where much of my confusion
came.

>  Does it make sense now? 
Yes, it finally clicked this morning around 5:00 am when I was
driving.  I now understand the reason for the */ part of the syntax.

Ultimately the OP's wishes would be best/most accurately met using the
find command from what I can gather.

dirs=`find -maxdepth 1 -type d \! -regex "^\.$"`
(the \! -regex "^.$" to eliminate the . directory)
files=`find -maxdepth 1 -type f`

Or to remove the path name (./) to have only the file names (or
directory names), I would use:
files=`find -maxdepth 1 -type f -printf "%f "`
resulting in a space delimited output.

Jacques B.

[Cameron Simpson]

On 29Jan2007 10:18, Daniel Qarras <dqarras(a)yahoo.com&gt; wrote:
| Yes, I am painfully aware of the power of zsh :)

Please, come to the Dark Side with us!

| But in this case I
| need to do my script with bash and it seems that although globbing for
| directories is trivial ( */ ) there is no similar pattern to match
| files. Oh, well, I guess I'll need to waste some CPU cycles and launch
| find everytime I need to know file names in the current directory.

Gah! No!

  files=
  for f in *
  do [ -f "$f" ] && files="$files $f"
  done
  ... do stuff with $files ...

If you've got to deal with filenames with whitespace in them you need to
be trickier.

BTW, the above works in plain Bourne shell - no zsh or bash extensions
needed.
-- 
Cameron Simpson <cs(a)zip.com.au&gt; DoD#743
http://www.cskk.ezoshosting.com/cs/

Q: What's the difference between a psychotic and a neurotic?
A: A psychotic doesn't believe that 2 + 2 = 4.  A neurotic knows it's true,
   but it bothers him.

[Daniel Qarras]

Hi!

>  | But in this case I
>  | need to do my script with bash and it seems that although globbing
>  for
>  | directories is trivial ( */ ) there is no similar pattern to match
>  | files. Oh, well, I guess I'll need to waste some CPU cycles and
>  launch
>  | find everytime I need to know file names in the current directory.
>  
>  Gah! No!
>  
>    files=
>    for f in *
>    do [ -f "$f" ] && files="$files $f"
>    done
>    ... do stuff with $files ...
>  
>  If you've got to deal with filenames with whitespace in them you need
>  to be trickier. 
Thanks, I'll be using this one.

PS. A hard headed zsh user would continue to complain that there's no
way to differ between files and links in bash without find but I won't
go into that :)

Cheers!




 
____________________________________________________________________________________
Sucker-punch spam with award-winning protection. 
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html

[Jacques B.]

>  >   files=
>  >   for f in *
>  >   do [ -f "$f" ] && files="$files $f"
>  >   done
>  >   ... do stuff with $files ...
>  >
>  > If you've got to deal with filenames with whitespace in them you need
>  > to be trickier. 
I like how this works.  But you are right, it does cause a problem for
filenames with spaces.  As far as cpu time (preceding the command with
"time" to get same), we are only talking a few 1/100th of a second
difference with the find command.  The find command is more robust as
it will properly deal with filenames with spaces.  Not to mention find
will also yield hidden files (i.e. .file) whereas the above won't.
All depends on your needs as to which will serve you better.

I've enjoyed this thread.  Anytime I can learn something new about
BASH then it's all good.

Jacques B.

[Steve Friedman]

On Tue, 30 Jan 2007, Jacques B. wrote:

> > >   files=
> > >   for f in *
> > >   do [ -f "$f" ] && files="$files $f"
> > >   done
> > >   ... do stuff with $files ...
> > >
> > > If you've got to deal with filenames with whitespace in them you need
> > > to be trickier.
>
>  I like how this works.  But you are right, it does cause a problem for
>  filenames with spaces.  As far as cpu time (preceding the command with
>  "time" to get same), we are only talking a few 1/100th of a second
>  difference with the find command.  The find command is more robust as
>  it will properly deal with filenames with spaces.  Not to mention find
>  will also yield hidden files (i.e. .file) whereas the above won't.
>  All depends on your needs as to which will serve you better.
>  
Note, that find also solves another problem:  namely, that if the globbing 
generates a line length beyond the max for bash (in either the for or the 
concatenation), then the script will fail.  This won't happen with find.

Steve Friedman

[Cameron Simpson]

On 30Jan2007 16:43, Steve Friedman <steve(a)adsi-m4.com&gt; wrote:
| Note, that find also solves another problem:  namely, that if the globbing 
| generates a line length beyond the max for bash (in either the for or the 
| concatenation), then the script will fail.  This won't happen with find.

That's pretty big. Note that the for loop is _not_ subject to the
command line exec argument length limit, because no program is being
exec()ed.
-- 
Cameron Simpson <cs(a)zip.com.au&gt; DoD#743
http://www.cskk.ezoshosting.com/cs/

"How do you know I'm Mad?" asked Alice.
"You must be," said the Cat, "or you wouldn't have come here."

[Cameron Simpson]

On 30Jan2007 15:24, Jacques B. <jjrboucher(a)gmail.com&gt; wrote:
| >>   files=
| >>   for f in *
| >>   do [ -f "$f" ] && files="$files $f"
| >>   done
| >>   ... do stuff with $files ...
| >>
| >> If you've got to deal with filenames with whitespace in them you need
| >> to be trickier.
| 
| I like how this works.  But you are right, it does cause a problem for
| filenames with spaces.  As far as cpu time (preceding the command with
| "time" to get same), we are only talking a few 1/100th of a second
| difference with the find command.

No. For _one_ run the cost is small. If something calls this code many
times, find is MANY MANY times more costly that an in-shell forkless
piece of code.

| The find command is more robust as
| it will properly deal with filenames with spaces.  Not to mention find
| will also yield hidden files (i.e. .file) whereas the above won't.

This depends what you want. But yes. But you can do this:

  for f in .* *
  do
    case "$f" in . | .. ) continue ;; esac

which gets it all.
-- 
Cameron Simpson <cs(a)zip.com.au&gt; DoD#743
http://www.cskk.ezoshosting.com/cs/

The word is not the thing.
The map is not the territory.
The symbol is not the thing symbolized.  - S.I. Hayakawa

[Todd Zullinger]

Cameron Simpson wrote:
>  On 30Jan2007 15:24, Jacques B. <jjrboucher(a)gmail.com&gt; wrote:
[...]
>  | The find command is more robust as it will properly deal with
>  | filenames with spaces.  Not to mention find will also yield hidden
>  | files (i.e. .file) whereas the above won't.
>  
>  This depends what you want. But yes. But you can do this:
>  
>    for f in .* *
>    do
>      case "$f" in . | .. ) continue ;; esac
>  
>  which gets it all. 
With bash you can also use "shopt -s dotglob" to allow * to match
filenames beginning with a dot.  I find that one handy. :)

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
======================================================================
Remember, there's a big difference between kneeling down and bending
over.
    -- Frank Zappa

[Cameron Simpson]

On 30Jan2007 09:08, Daniel Qarras <dqarras(a)yahoo.com&gt; wrote:
| PS. A hard headed zsh user would continue to complain that there's no
| way to differ between files and links in bash without find but I won't
| go into that :)

A POSIX shell requires that the test command supports this:

       -h  file
              True if file exists and is a symbolic link.
       -L  file
              True if file exists and is a symbolic link.

There are two letters for historic reasons. Bash supports both, and so
does zsh.

Of course, if you mean a hardlink, then you're asking a question
that is meaningless.

BTW, I tend to test directorishness like this:

  [ -d foo/. ]

which works for a directory or a symlink that resolves to a directory.
-- 
Cameron Simpson <cs(a)zip.com.au&gt; DoD#743
http://www.cskk.ezoshosting.com/cs/

I am a kind of burr; I shall stick.
        - William Shakespeare, _Measure for Measure_

[Daniel Qarras]

Hi!

--- Cameron Simpson <cs(a)zip.com.au&gt; wrote:

>  A POSIX shell requires that the test command supports this:
>  
>         -h  file
>                True if file exists and is a symbolic link.
>         -L  file
>                True if file exists and is a symbolic link. 
Thanks, I already saw those but initially they did not work for
directories. That was because I had

dirs=[^.]*/

that would expand, e.g:

foo/
bar/

and the trailing slash caused -L test to fail. So, finally, I have what
I wanted without any external commands like this:

dirs=[^.]*/
for d in ${dirs}
do
  if [[ -d ${d//\//} && ! -L ${d//\//} ]]
  then
    echo processing dir $d
  fi
done
# ...
files=[^.]*
for f in ${files}
do
  if [[ -f ${f//\//} && ! -L ${f//\//} ]]
  then
    echo processing files $f
  fi
done

Thanks!




 
____________________________________________________________________________________
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html

[Cameron Simpson]

On 31Jan2007 08:47, Daniel Qarras <dqarras(a)yahoo.com&gt; wrote:
| > A POSIX shell requires that the test command supports this:
| > 
| >        -h  file
| >               True if file exists and is a symbolic link.
| >        -L  file
| >               True if file exists and is a symbolic link.
| 
| Thanks, I already saw those but initially they did not work for
| directories. That was because I had
| 
| dirs=[^.]*/
| 
| that would expand, e.g:
| 
| foo/
| bar/
| 
| and the trailing slash caused -L test to fail.

Indeed, because it forces a test to be _not_ on the symlink but on what
is on the far side of it.

BTW, if you've been following this thread you should know that:

  [^.]*/

is better written:

  */

which means _exactly_ the same thing.

Of course, you realise that you may not need to test for -d at all
because */ will only return directories (or things pointing at them).
(Except when there are no directories at all - the it returns "*/"
unchanged and you just need to test for existence.)

Cheers,
-- 
Cameron Simpson <cs(a)zip.com.au&gt; DoD#743
http://www.cskk.ezoshosting.com/cs/

Haven't been there. Don't want to go. Don't need another t-shirt!
        - Lisa Varner <varner(a)freenet.columbus.oh.us&gt;

[Evan Klitzke]

On Sun, 2007-01-28 at 12:12 -0800, Daniel Qarras wrote:
>  Hi all,
>  
>  with Bash one can list directories (excluding dot dirs) like this:
>  
>  ls [^.]*/
>  
>  How can I list files instead of directories with Bash? I thought this
>  would be trivial but I can't find a solution anywhere. 
Daniel,

My knowledge of bash is very limited, but I believe that the -d
conditional checks if a file is a directory. So you could define a
function something like this (the syntax is probably all wrong, but
hopefully it is decipherable):

for file in `ls -1`; do
    if ![ -d file]; then
        printf "$file\n"
    fi
end

Name the function something like "lsfiles" and you're good to go.

[Steven W. Orr]

On Monday, Jan 29th 2007 at 12:14 -0800, quoth Evan Klitzke:

=>My knowledge of bash is very limited, but I believe that the -d
=>conditional checks if a file is a directory. So you could define a
=>function something like this (the syntax is probably all wrong, but
=>hopefully it is decipherable):
=>
=>for file in `ls -1`; do
=>    if ![ -d file]; then
=>        printf "$file\n"
=>    fi
=>end
=>
=>Name the function something like "lsfiles" and you're good to go.

lsfiles ()
{
    typeset file
    typeset files

    (( $# > 1 )) && echo 'Extra args ignored.' 1>&2
    [[ -z "$1" ]] && files='*' || files="$@"
    for file in $files
    do
        [ -d $file ] || ls -d $file
    done
}

Here's one just for fun. If people are having varying results then look at 
the various variables that control globbing. None of them will be found in 
the inputrc ;-)

-- 
steveo at syslang dot net TMMP1 http://frambors.syslang.net/
Do you have neighbors who are not frambors?

[Rick Stevens]

On Mon, 2007-01-29 at 12:14 -0800, Evan Klitzke wrote:
>  On Sun, 2007-01-28 at 12:12 -0800, Daniel Qarras wrote:
>  > Hi all,
>  > 
>  > with Bash one can list directories (excluding dot dirs) like this:
>  > 
>  > ls [^.]*/
>  > 
>  > How can I list files instead of directories with Bash? I thought this
>  > would be trivial but I can't find a solution anywhere.
>  
>  Daniel,
>  
>  My knowledge of bash is very limited, but I believe that the -d
>  conditional checks if a file is a directory. So you could define a
>  function something like this (the syntax is probably all wrong, but
>  hopefully it is decipherable):
>  
>  for file in `ls -1`; do
>      if ![ -d file]; then
>          printf "$file\n"
>      fi
>  end
>  
>  Name the function something like "lsfiles" and you're good to go. 
Uh, how about "find . -maxdepth 1 -type f -print" to list the files and
"find . -maxdepth 1 -type d -print" for directories?  Take out the
"-maxdepth 1" and it'll walk the directory tree.

Nah, too prosaic!

----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer     rstevens(a)vitalstream.com -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
-     Make it idiot proof and someone will make a better idiot.      -
----------------------------------------------------------------------

[Evan Klitzke]

On Mon, 2007-01-29 at 14:38 -0800, Rick Stevens wrote:

>  Uh, how about "find . -maxdepth 1 -type f -print" to list
> the files and
>  "find . -maxdepth 1 -type d -print" for directories?  Take out the
>  "-maxdepth 1" and it'll walk the directory tree.
>  
>  Nah, too prosaic! 
Next you'll be telling me that "cat foo | grep bar" is redundant!

-- Evan Klitzke