|
Home > Archive > Unix Shell > May 2007 > how to detect the dir to cd to begins with a dot
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 |
how to detect the dir to cd to begins with a dot
|
|
| paintedjazz@gmail.com 2007-05-18, 1:18 am |
| Is there a way in a bash script to detect if the directory one is
about to cd into is a directory that begins with a dot?
e.g.
find . -type d |
while read dir
do
if [ $dir begins with a dot ]
then
continue
else
do stuff
fi
done
Thanks much.
| |
| paintedjazz@gmail.com 2007-05-18, 1:18 am |
| On May 17, 6:14 pm, paintedj...@gmail.com wrote:
> Is there a way in a bash script to detect if the directory one is
> about to cd into is a directory that begins with a dot?
>
> e.g.
>
> find . -type d |
> while read dir
> do
> if [ $dir begins with a dot ]
> then
> continue
> else
> do stuff
> fi
> done
>
> Thanks much.
This seems to work:
find . -type d |
while read DIR ; do
if echo "$DIR" |grep "^\." ; then
continue
else
cd "$DIR"
fi
done
| |
| James Michael Fultz 2007-05-18, 1:18 am |
| * paintedjazz@gmail.com <paintedjazz@gmail.com>:
> On May 17, 6:14 pm, paintedj...@gmail.com wrote:
[ ... ][vbcol=seagreen]
> This seems to work:
>
> find . -type d |
> while read DIR ; do
> if echo "$DIR" |grep "^\." ; then
> continue
> else
> cd "$DIR"
> fi
> done
You can save a call to an external program by using case:
find . -type d -print |
while IFS= read -r DIR ; do
case "$DIR" in
.*)
continue
;;
*)
cd "$DIR"
;;
esac
done
Alternately, you could move the test upto find itself:
find . -type d ! -name '.*' -print |
while IFS= read -r DIR ; do
cd "$DIR"
done
--
James Michael Fultz <xyzzy@sent.as.invalid>
Remove this part when replying ^^^^^^^^
| |
| Harry331 2007-05-18, 1:18 am |
| paintedjazz@gmail.com wrote...
>
>Is there a way in a bash script to detect if the directory one is
>about to cd into is a directory that begins with a dot?
>
>e.g.
>
>find . -type d |
> while read dir
> do
> if [ $dir begins with a dot ]
> then
> continue
> else
> do stuff
> fi
> done
everything from
find . -type d
starts with a dot.
e.g.
$ cd /cygdrive/c/cygwin
$ find . -type d
..
../etc
../etc/setup
../etc/postinstall
../etc/defaults
../etc/defaults/etc
[snip]
Isn't it?
| |
| James Michael Fultz 2007-05-19, 1:20 am |
| * Harry331 <harryooopotter@hotmail.co_>:
> paintedjazz@gmail.com wrote...
>
> everything from
> find . -type d
> starts with a dot.
>
> e.g.
>
> $ cd /cygdrive/c/cygwin
> $ find . -type d
> .
> ./etc
> ./etc/setup
> ./etc/postinstall
> ./etc/defaults
> ./etc/defaults/etc
> [snip]
>
> Isn't it?
You are quite right! Something I overlooked too. I suppose the
simplest solution using find is to have find itself test for and exclude
directories beginning with a dot.
$ ls -A
..quux bar baz foo
$ find . -type d ! -name '.*' -print
../foo
../bar
../baz
--
James Michael Fultz <xyzzy@sent.as.invalid>
Remove this part when replying ^^^^^^^^
| |
| Chris F.A. Johnson 2007-05-19, 1:20 am |
| On 2007-05-18, James Michael Fultz wrote:
> * paintedjazz@gmail.com <paintedjazz@gmail.com>:
> [ ... ]
>
> You can save a call to an external program by using case:
>
> find . -type d -print |
> while IFS= read -r DIR ; do
> case "$DIR" in
Strip the leading ./:
case "${DIR#./}" in
> .*)
> continue
> ;;
> *)
> cd "$DIR"
And isolate the cd in a subhsell:
(
cd "$DIR"
....
)
> ;;
> esac
> done
>
> Alternately, you could move the test upto find itself:
>
> find . -type d ! -name '.*' -print |
> while IFS= read -r DIR ; do
> cd "$DIR"
> done
>
--
Chris F.A. Johnson, author <http://cfaj.freeshell.org/shell/>
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
===== My code in this post, if any, assumes the POSIX locale
===== and is released under the GNU General Public Licence
| |
| Stephane CHAZELAS 2007-05-20, 7:19 am |
| 2007-05-17, 18:14(-07), paintedjazz@gmail.com:
> Is there a way in a bash script to detect if the directory one is
> about to cd into is a directory that begins with a dot?
>
> e.g.
>
> find . -type d |
> while read dir
> do
> if [ $dir begins with a dot ]
> then
> continue
> else
> do stuff
> fi
> done
[...]
case ${dir##*/} in
(.*) ...
esac
Note that find's output is not post-processable unless you use
some trick or can guarantee that none of the file names contain
newline characters. find has a -exec predicate, there should be
no need to use a while loop.
read alone is for something very special. If you want to read a
line of input, it's IFS= read -r dir.
Note that there's no guarantee that the while loop will or will
not be run in a subshell in the code above. So if for instance
you do a cd in that loop, it may only change the current
directory of that subshell.
--
Stéphane
| |
| paintedjazz@gmail.com 2007-05-21, 1:19 pm |
| On May 20, 3:57 am, Stephane CHAZELAS <this.addr...@is.invalid> wrote:
> 2007-05-17, 18:14(-07), paintedj...@gmail.com:
> Is there a way in a bash script to detect if the directory one is
>
>
>
> [...]
>
> case ${dir##*/} in
> (.*) ...
> esac
>
> Note that find's output is not post-processable unless you use
> some trick or can guarantee that none of the file names contain
> newline characters.
Do you mean using eval as the "some trick"?
..=2E. for example:
eval 'find . -type d' -exec ...
Can a case statement follow a -exec ?
Does it require a special format because
of the double semi-colons and esac?
Also, why is it that find's output is not post-processable?
Is it just because the filename may contain a space, tab,
newline, backslash, single or double quote characters?
[just read your April 17 post when I searched the net
for post-processable and find] Other than that,
find doesn't write to stdout differently than any
other program, I hope.
Also, I learned about using eval in the manner above
on this ng a while back. May I ask what eval does to make
such a find command succeed instead of fail?
> find has a -exec predicate, there should be
> no need to use a while loop.
>
> read alone is for something very special. If you want to read a
> line of input, it's IFS=3D read -r dir.
>
> Note that there's no guarantee that the while loop will or will
> not be run in a subshell in the code above.
If I may ask one more question, why is a subshell created?
Because of the pipe?
> So if for instance
> you do a cd in that loop, it may only change the current
> directory of that subshell.
>
> --
> St=E9phane
| |
| paintedjazz@gmail.com 2007-05-21, 1:19 pm |
| On May 20, 3:57 am, Stephane CHAZELAS <this.addr...@is.invalid> wrote:
> 2007-05-17, 18:14(-07), paintedj...@gmail.com:
> Is there a way in a bash script to detect if the directory one is
>
>
>
> [...]
>
> case ${dir##*/} in
> (.*) ...
> esac
>
> Note that find's output is not post-processable unless you use
> some trick or can guarantee that none of the file names contain
> newline characters.
Do you mean using eval as the "some trick"?
..=2E. for example:
eval 'find . -type d' -exec ...
Can a case statement follow a -exec ?
Does it require a special format because
of the double semi-colons and esac?
Also, why is it that find's output is not post-processable?
Is it just because the filename may contain a space, tab,
newline, backslash, single or double quote characters?
[just read your April 17 post when I searched the net
for post-processable and find] Other than that,
find doesn't write to stdout differently than any
other program, I hope.
Also, I learned about using eval in the manner above
on this ng a while back. May I ask what eval does to make
such a find command succeed instead of fail?
> find has a -exec predicate, there should be
> no need to use a while loop.
>
> read alone is for something very special. If you want to read a
> line of input, it's IFS=3D read -r dir.
>
> Note that there's no guarantee that the while loop will or will
> not be run in a subshell in the code above.
If I may ask one more question, why is a subshell created?
Because of the pipe?
> So if for instance
> you do a cd in that loop, it may only change the current
> directory of that subshell.
>
> --
> St=E9phane
| |
| Stephane CHAZELAS 2007-05-21, 1:19 pm |
| 2007-05-21, 09:54(-07), paintedjazz@gmail.com:
[...]
>
> Do you mean using eval as the "some trick"?
> ... for example:
>
> eval 'find . -type d' -exec ...
No I mean tricks like
find .//. ...
so that there's a specific pattern in find's output that allows
one to find out which line each file path starts on.
> Can a case statement follow a -exec ?
> Does it require a special format because
> of the double semi-colons and esac?
>
> Also, why is it that find's output is not post-processable?
> Is it just because the filename may contain a space, tab,
> newline, backslash, single or double quote characters?
Just because you can't retreive the information from find's
output.
in:
../a/b
../b
You don't know if that's two files "./a/b" and "./b" or one
single file: "./a/b\n./b"
> [just read your April 17 post when I searched the net
> for post-processable and find] Other than that,
> find doesn't write to stdout differently than any
> other program, I hope.
No, but it writes a file path list separating them with a
<newline> terminator without escaping separators that may exist
in the file paths.
> Also, I learned about using eval in the manner above
> on this ng a while back. May I ask what eval does to make
> such a find command succeed instead of fail?
Well, at least in:
eval 'find . -type d' -exec ...
it does nothing useful that I can tell.
[...]
>
> If I may ask one more question, why is a subshell created?
> Because of the pipe?
Yes. a pipe is between two processes. At least one can
not be the current shell. Often (as in bash, pdksh... none is).
--
Stéphane
| |
| Bill Marcum 2007-05-21, 1:19 pm |
| On 17 May 2007 18:14:20 -0700, paintedjazz@gmail.com
<paintedjazz@gmail.com> wrote:
>
>
> Is there a way in a bash script to detect if the directory one is
> about to cd into is a directory that begins with a dot?
>
> e.g.
>
> find . -type d |
> while read dir
> do
> if [ $dir begins with a dot ]
> then
> continue
> else
> do stuff
> fi
> done
>
> Thanks much.
>
find . -type d \! -name '.*' -exec do_stuff \;
--
A verbal contract isn't worth the paper it's written on.
-- Samuel Goldwyn
|
|
|
|
|