Find a specific file in the nearest ancestor of the current working directory
Clash Royale CLAN TAG#URR8PPP
I'd like to find a way to find a given file by looking upward in the directory structure, rather than recursively searching through child directories.
There's a node module that appears to do exactly what I want, but I don't want to depend on installing JavaScript or packages like that. Is there a shell command for this? A way to make find
do that? Or a standard approach that I just wasn't able to find through Googling?
shell-script files find directory
add a comment |
I'd like to find a way to find a given file by looking upward in the directory structure, rather than recursively searching through child directories.
There's a node module that appears to do exactly what I want, but I don't want to depend on installing JavaScript or packages like that. Is there a shell command for this? A way to make find
do that? Or a standard approach that I just wasn't able to find through Googling?
shell-script files find directory
Do you also want this behavior of that node module? "If X/.dir/file.ext exists, return it." (that searches an immediate sub directory of X, not purely ancestors)
– Jeff Schaller
Jul 2 '16 at 14:27
add a comment |
I'd like to find a way to find a given file by looking upward in the directory structure, rather than recursively searching through child directories.
There's a node module that appears to do exactly what I want, but I don't want to depend on installing JavaScript or packages like that. Is there a shell command for this? A way to make find
do that? Or a standard approach that I just wasn't able to find through Googling?
shell-script files find directory
I'd like to find a way to find a given file by looking upward in the directory structure, rather than recursively searching through child directories.
There's a node module that appears to do exactly what I want, but I don't want to depend on installing JavaScript or packages like that. Is there a shell command for this? A way to make find
do that? Or a standard approach that I just wasn't able to find through Googling?
shell-script files find directory
shell-script files find directory
edited Jul 2 '16 at 13:04
Jeff Schaller
41.2k1056131
41.2k1056131
asked Jul 1 '16 at 23:07
iconoclasticonoclast
3,80163870
3,80163870
Do you also want this behavior of that node module? "If X/.dir/file.ext exists, return it." (that searches an immediate sub directory of X, not purely ancestors)
– Jeff Schaller
Jul 2 '16 at 14:27
add a comment |
Do you also want this behavior of that node module? "If X/.dir/file.ext exists, return it." (that searches an immediate sub directory of X, not purely ancestors)
– Jeff Schaller
Jul 2 '16 at 14:27
Do you also want this behavior of that node module? "If X/.dir/file.ext exists, return it." (that searches an immediate sub directory of X, not purely ancestors)
– Jeff Schaller
Jul 2 '16 at 14:27
Do you also want this behavior of that node module? "If X/.dir/file.ext exists, return it." (that searches an immediate sub directory of X, not purely ancestors)
– Jeff Schaller
Jul 2 '16 at 14:27
add a comment |
3 Answers
3
active
oldest
votes
This is a direct translation of the find-config algorithm in generic shell commands (tested under bash, ksh, and zsh), where I use a return code of 0 to mean success and 1 to mean NULL/failure.
findconfig()
# from: https://www.npmjs.com/package/find-config#algorithm
# 1. If X/file.ext exists and is a regular file, return it. STOP
# 2. If X has a parent directory, change X to parent. GO TO 1
# 3. Return NULL.
if [ -f "$1" ]; then
printf '%sn' "$PWD%//$1"
elif [ "$PWD" = / ]; then
false
else
# a subshell so that we don't affect the caller's $PWD
(cd .. && findconfig "$1")
fi
Sample run, with the setup stolen copied and extended from Stephen Harris's answer:
$ mkdir -p ~/tmp/iconoclast
$ cd ~/tmp/iconoclast
$ mkdir -p A/B/C/D/E/F A/good/show
$ touch A/good/show/this A/B/C/D/E/F/srchup A/B/C/thefile
$ cd A/B/C/D/E/F
$ findconfig thefile
/home/jeff/tmp/iconoclast/A/B/C/thefile
$ echo "$?"
0
$ findconfig foobar
$ echo "$?"
1
Why is.dir
hard-coded into the function?
– iconoclast
Jan 22 at 17:20
@iconoclast on account of the spec referenced in the question: npmjs.com/package/find-config
– Jeff Schaller
Jan 22 at 17:23
I don't think the.dir
given here is meant to be taken literally. I certainly hope not, because that would make this NPM package not very useful.
– iconoclast
Jan 22 at 19:00
It's possible I misunderstood, then! I'm not familiar with node.js. Is it your understanding that the code is checking for the file in the/any immediate subdirectory?
– Jeff Schaller
Jan 22 at 19:05
1
it's just checking in the current directory and its parents. So I think we can just remove the second line of code inside the function, and it looks like it should work nicely.—I just updated the code (and tested it first, briefly) but I didn't update the sample run
– iconoclast
Jan 22 at 20:15
add a comment |
A simple loop of checking the current directory and if it's not found then strip off the last component would work
#!/bin/bash
wantfile="$1"
dir=$(realpath .)
found=""
while [ -z "$found" -a -n "$dir" ]
do
if [ -e "$dir/$wantfile" ]
then
found="$dir/$wantfile"
fi
dir=$dir%/*
done
if [ -z "$found" ]
then
echo Can not find: $wantfile
else
echo Found: $found
fi
For example, if this is the directory tree:
$ find /tmp/A
/tmp/A
/tmp/A/good
/tmp/A/good/show
/tmp/A/good/show/this
/tmp/A/B
/tmp/A/B/C
/tmp/A/B/C/thefile
/tmp/A/B/C/D
/tmp/A/B/C/D/E
/tmp/A/B/C/D/E/F
/tmp/A/B/C/D/E/F/srchup
$ pwd
/tmp/A/B/C/D/E/F
$ ./srchup thefile
Found: /tmp/A/B/C/thefile
We can see that the search went up the tree until it found what we were looking for.
add a comment |
One way to do it:
#! /bin/sh
dir=$(pwd -P)
while [ -n "$dir" -a ! -f "$dir/$1" ]; do
dir=$dir%/*
done
if [ -f "$dir/$1" ]; then printf '%sn' "$dir/$1"; fi
Replace pwd -P
by pwd -L
if you want to follow symlinks instead of checking physical directories.
Any reason you use-a
?[ -n "$dir" ] && ! [ -f "$dir/$1" ]
is more reliable. (Exercise: Try determining correct parsing for[ -n "$a" -a "$b" = "$c" ]
ifa='='
andb='-o'
.)
– Wildcard
Jul 2 '16 at 5:19
@Wildcard Because I'm an old fart and set in my bad old ways. :) Also, because it avoids running a second[
on shells where[
is not a builtin. As for[ -n "$a" -a "$b" = "$c" ]
, that's why you always writex"$b" = x"$c"
rather than just"$b" = "$c"
.
– Satō Katsura
Jul 2 '16 at 5:30
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f293393%2ffind-a-specific-file-in-the-nearest-ancestor-of-the-current-working-directory%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
This is a direct translation of the find-config algorithm in generic shell commands (tested under bash, ksh, and zsh), where I use a return code of 0 to mean success and 1 to mean NULL/failure.
findconfig()
# from: https://www.npmjs.com/package/find-config#algorithm
# 1. If X/file.ext exists and is a regular file, return it. STOP
# 2. If X has a parent directory, change X to parent. GO TO 1
# 3. Return NULL.
if [ -f "$1" ]; then
printf '%sn' "$PWD%//$1"
elif [ "$PWD" = / ]; then
false
else
# a subshell so that we don't affect the caller's $PWD
(cd .. && findconfig "$1")
fi
Sample run, with the setup stolen copied and extended from Stephen Harris's answer:
$ mkdir -p ~/tmp/iconoclast
$ cd ~/tmp/iconoclast
$ mkdir -p A/B/C/D/E/F A/good/show
$ touch A/good/show/this A/B/C/D/E/F/srchup A/B/C/thefile
$ cd A/B/C/D/E/F
$ findconfig thefile
/home/jeff/tmp/iconoclast/A/B/C/thefile
$ echo "$?"
0
$ findconfig foobar
$ echo "$?"
1
Why is.dir
hard-coded into the function?
– iconoclast
Jan 22 at 17:20
@iconoclast on account of the spec referenced in the question: npmjs.com/package/find-config
– Jeff Schaller
Jan 22 at 17:23
I don't think the.dir
given here is meant to be taken literally. I certainly hope not, because that would make this NPM package not very useful.
– iconoclast
Jan 22 at 19:00
It's possible I misunderstood, then! I'm not familiar with node.js. Is it your understanding that the code is checking for the file in the/any immediate subdirectory?
– Jeff Schaller
Jan 22 at 19:05
1
it's just checking in the current directory and its parents. So I think we can just remove the second line of code inside the function, and it looks like it should work nicely.—I just updated the code (and tested it first, briefly) but I didn't update the sample run
– iconoclast
Jan 22 at 20:15
add a comment |
This is a direct translation of the find-config algorithm in generic shell commands (tested under bash, ksh, and zsh), where I use a return code of 0 to mean success and 1 to mean NULL/failure.
findconfig()
# from: https://www.npmjs.com/package/find-config#algorithm
# 1. If X/file.ext exists and is a regular file, return it. STOP
# 2. If X has a parent directory, change X to parent. GO TO 1
# 3. Return NULL.
if [ -f "$1" ]; then
printf '%sn' "$PWD%//$1"
elif [ "$PWD" = / ]; then
false
else
# a subshell so that we don't affect the caller's $PWD
(cd .. && findconfig "$1")
fi
Sample run, with the setup stolen copied and extended from Stephen Harris's answer:
$ mkdir -p ~/tmp/iconoclast
$ cd ~/tmp/iconoclast
$ mkdir -p A/B/C/D/E/F A/good/show
$ touch A/good/show/this A/B/C/D/E/F/srchup A/B/C/thefile
$ cd A/B/C/D/E/F
$ findconfig thefile
/home/jeff/tmp/iconoclast/A/B/C/thefile
$ echo "$?"
0
$ findconfig foobar
$ echo "$?"
1
Why is.dir
hard-coded into the function?
– iconoclast
Jan 22 at 17:20
@iconoclast on account of the spec referenced in the question: npmjs.com/package/find-config
– Jeff Schaller
Jan 22 at 17:23
I don't think the.dir
given here is meant to be taken literally. I certainly hope not, because that would make this NPM package not very useful.
– iconoclast
Jan 22 at 19:00
It's possible I misunderstood, then! I'm not familiar with node.js. Is it your understanding that the code is checking for the file in the/any immediate subdirectory?
– Jeff Schaller
Jan 22 at 19:05
1
it's just checking in the current directory and its parents. So I think we can just remove the second line of code inside the function, and it looks like it should work nicely.—I just updated the code (and tested it first, briefly) but I didn't update the sample run
– iconoclast
Jan 22 at 20:15
add a comment |
This is a direct translation of the find-config algorithm in generic shell commands (tested under bash, ksh, and zsh), where I use a return code of 0 to mean success and 1 to mean NULL/failure.
findconfig()
# from: https://www.npmjs.com/package/find-config#algorithm
# 1. If X/file.ext exists and is a regular file, return it. STOP
# 2. If X has a parent directory, change X to parent. GO TO 1
# 3. Return NULL.
if [ -f "$1" ]; then
printf '%sn' "$PWD%//$1"
elif [ "$PWD" = / ]; then
false
else
# a subshell so that we don't affect the caller's $PWD
(cd .. && findconfig "$1")
fi
Sample run, with the setup stolen copied and extended from Stephen Harris's answer:
$ mkdir -p ~/tmp/iconoclast
$ cd ~/tmp/iconoclast
$ mkdir -p A/B/C/D/E/F A/good/show
$ touch A/good/show/this A/B/C/D/E/F/srchup A/B/C/thefile
$ cd A/B/C/D/E/F
$ findconfig thefile
/home/jeff/tmp/iconoclast/A/B/C/thefile
$ echo "$?"
0
$ findconfig foobar
$ echo "$?"
1
This is a direct translation of the find-config algorithm in generic shell commands (tested under bash, ksh, and zsh), where I use a return code of 0 to mean success and 1 to mean NULL/failure.
findconfig()
# from: https://www.npmjs.com/package/find-config#algorithm
# 1. If X/file.ext exists and is a regular file, return it. STOP
# 2. If X has a parent directory, change X to parent. GO TO 1
# 3. Return NULL.
if [ -f "$1" ]; then
printf '%sn' "$PWD%//$1"
elif [ "$PWD" = / ]; then
false
else
# a subshell so that we don't affect the caller's $PWD
(cd .. && findconfig "$1")
fi
Sample run, with the setup stolen copied and extended from Stephen Harris's answer:
$ mkdir -p ~/tmp/iconoclast
$ cd ~/tmp/iconoclast
$ mkdir -p A/B/C/D/E/F A/good/show
$ touch A/good/show/this A/B/C/D/E/F/srchup A/B/C/thefile
$ cd A/B/C/D/E/F
$ findconfig thefile
/home/jeff/tmp/iconoclast/A/B/C/thefile
$ echo "$?"
0
$ findconfig foobar
$ echo "$?"
1
edited Jan 22 at 22:40
Stéphane Chazelas
305k57574928
305k57574928
answered Jul 2 '16 at 14:57
Jeff SchallerJeff Schaller
41.2k1056131
41.2k1056131
Why is.dir
hard-coded into the function?
– iconoclast
Jan 22 at 17:20
@iconoclast on account of the spec referenced in the question: npmjs.com/package/find-config
– Jeff Schaller
Jan 22 at 17:23
I don't think the.dir
given here is meant to be taken literally. I certainly hope not, because that would make this NPM package not very useful.
– iconoclast
Jan 22 at 19:00
It's possible I misunderstood, then! I'm not familiar with node.js. Is it your understanding that the code is checking for the file in the/any immediate subdirectory?
– Jeff Schaller
Jan 22 at 19:05
1
it's just checking in the current directory and its parents. So I think we can just remove the second line of code inside the function, and it looks like it should work nicely.—I just updated the code (and tested it first, briefly) but I didn't update the sample run
– iconoclast
Jan 22 at 20:15
add a comment |
Why is.dir
hard-coded into the function?
– iconoclast
Jan 22 at 17:20
@iconoclast on account of the spec referenced in the question: npmjs.com/package/find-config
– Jeff Schaller
Jan 22 at 17:23
I don't think the.dir
given here is meant to be taken literally. I certainly hope not, because that would make this NPM package not very useful.
– iconoclast
Jan 22 at 19:00
It's possible I misunderstood, then! I'm not familiar with node.js. Is it your understanding that the code is checking for the file in the/any immediate subdirectory?
– Jeff Schaller
Jan 22 at 19:05
1
it's just checking in the current directory and its parents. So I think we can just remove the second line of code inside the function, and it looks like it should work nicely.—I just updated the code (and tested it first, briefly) but I didn't update the sample run
– iconoclast
Jan 22 at 20:15
Why is
.dir
hard-coded into the function?– iconoclast
Jan 22 at 17:20
Why is
.dir
hard-coded into the function?– iconoclast
Jan 22 at 17:20
@iconoclast on account of the spec referenced in the question: npmjs.com/package/find-config
– Jeff Schaller
Jan 22 at 17:23
@iconoclast on account of the spec referenced in the question: npmjs.com/package/find-config
– Jeff Schaller
Jan 22 at 17:23
I don't think the
.dir
given here is meant to be taken literally. I certainly hope not, because that would make this NPM package not very useful.– iconoclast
Jan 22 at 19:00
I don't think the
.dir
given here is meant to be taken literally. I certainly hope not, because that would make this NPM package not very useful.– iconoclast
Jan 22 at 19:00
It's possible I misunderstood, then! I'm not familiar with node.js. Is it your understanding that the code is checking for the file in the/any immediate subdirectory?
– Jeff Schaller
Jan 22 at 19:05
It's possible I misunderstood, then! I'm not familiar with node.js. Is it your understanding that the code is checking for the file in the/any immediate subdirectory?
– Jeff Schaller
Jan 22 at 19:05
1
1
it's just checking in the current directory and its parents. So I think we can just remove the second line of code inside the function, and it looks like it should work nicely.—I just updated the code (and tested it first, briefly) but I didn't update the sample run
– iconoclast
Jan 22 at 20:15
it's just checking in the current directory and its parents. So I think we can just remove the second line of code inside the function, and it looks like it should work nicely.—I just updated the code (and tested it first, briefly) but I didn't update the sample run
– iconoclast
Jan 22 at 20:15
add a comment |
A simple loop of checking the current directory and if it's not found then strip off the last component would work
#!/bin/bash
wantfile="$1"
dir=$(realpath .)
found=""
while [ -z "$found" -a -n "$dir" ]
do
if [ -e "$dir/$wantfile" ]
then
found="$dir/$wantfile"
fi
dir=$dir%/*
done
if [ -z "$found" ]
then
echo Can not find: $wantfile
else
echo Found: $found
fi
For example, if this is the directory tree:
$ find /tmp/A
/tmp/A
/tmp/A/good
/tmp/A/good/show
/tmp/A/good/show/this
/tmp/A/B
/tmp/A/B/C
/tmp/A/B/C/thefile
/tmp/A/B/C/D
/tmp/A/B/C/D/E
/tmp/A/B/C/D/E/F
/tmp/A/B/C/D/E/F/srchup
$ pwd
/tmp/A/B/C/D/E/F
$ ./srchup thefile
Found: /tmp/A/B/C/thefile
We can see that the search went up the tree until it found what we were looking for.
add a comment |
A simple loop of checking the current directory and if it's not found then strip off the last component would work
#!/bin/bash
wantfile="$1"
dir=$(realpath .)
found=""
while [ -z "$found" -a -n "$dir" ]
do
if [ -e "$dir/$wantfile" ]
then
found="$dir/$wantfile"
fi
dir=$dir%/*
done
if [ -z "$found" ]
then
echo Can not find: $wantfile
else
echo Found: $found
fi
For example, if this is the directory tree:
$ find /tmp/A
/tmp/A
/tmp/A/good
/tmp/A/good/show
/tmp/A/good/show/this
/tmp/A/B
/tmp/A/B/C
/tmp/A/B/C/thefile
/tmp/A/B/C/D
/tmp/A/B/C/D/E
/tmp/A/B/C/D/E/F
/tmp/A/B/C/D/E/F/srchup
$ pwd
/tmp/A/B/C/D/E/F
$ ./srchup thefile
Found: /tmp/A/B/C/thefile
We can see that the search went up the tree until it found what we were looking for.
add a comment |
A simple loop of checking the current directory and if it's not found then strip off the last component would work
#!/bin/bash
wantfile="$1"
dir=$(realpath .)
found=""
while [ -z "$found" -a -n "$dir" ]
do
if [ -e "$dir/$wantfile" ]
then
found="$dir/$wantfile"
fi
dir=$dir%/*
done
if [ -z "$found" ]
then
echo Can not find: $wantfile
else
echo Found: $found
fi
For example, if this is the directory tree:
$ find /tmp/A
/tmp/A
/tmp/A/good
/tmp/A/good/show
/tmp/A/good/show/this
/tmp/A/B
/tmp/A/B/C
/tmp/A/B/C/thefile
/tmp/A/B/C/D
/tmp/A/B/C/D/E
/tmp/A/B/C/D/E/F
/tmp/A/B/C/D/E/F/srchup
$ pwd
/tmp/A/B/C/D/E/F
$ ./srchup thefile
Found: /tmp/A/B/C/thefile
We can see that the search went up the tree until it found what we were looking for.
A simple loop of checking the current directory and if it's not found then strip off the last component would work
#!/bin/bash
wantfile="$1"
dir=$(realpath .)
found=""
while [ -z "$found" -a -n "$dir" ]
do
if [ -e "$dir/$wantfile" ]
then
found="$dir/$wantfile"
fi
dir=$dir%/*
done
if [ -z "$found" ]
then
echo Can not find: $wantfile
else
echo Found: $found
fi
For example, if this is the directory tree:
$ find /tmp/A
/tmp/A
/tmp/A/good
/tmp/A/good/show
/tmp/A/good/show/this
/tmp/A/B
/tmp/A/B/C
/tmp/A/B/C/thefile
/tmp/A/B/C/D
/tmp/A/B/C/D/E
/tmp/A/B/C/D/E/F
/tmp/A/B/C/D/E/F/srchup
$ pwd
/tmp/A/B/C/D/E/F
$ ./srchup thefile
Found: /tmp/A/B/C/thefile
We can see that the search went up the tree until it found what we were looking for.
answered Jul 1 '16 at 23:20
Stephen HarrisStephen Harris
25.9k24477
25.9k24477
add a comment |
add a comment |
One way to do it:
#! /bin/sh
dir=$(pwd -P)
while [ -n "$dir" -a ! -f "$dir/$1" ]; do
dir=$dir%/*
done
if [ -f "$dir/$1" ]; then printf '%sn' "$dir/$1"; fi
Replace pwd -P
by pwd -L
if you want to follow symlinks instead of checking physical directories.
Any reason you use-a
?[ -n "$dir" ] && ! [ -f "$dir/$1" ]
is more reliable. (Exercise: Try determining correct parsing for[ -n "$a" -a "$b" = "$c" ]
ifa='='
andb='-o'
.)
– Wildcard
Jul 2 '16 at 5:19
@Wildcard Because I'm an old fart and set in my bad old ways. :) Also, because it avoids running a second[
on shells where[
is not a builtin. As for[ -n "$a" -a "$b" = "$c" ]
, that's why you always writex"$b" = x"$c"
rather than just"$b" = "$c"
.
– Satō Katsura
Jul 2 '16 at 5:30
add a comment |
One way to do it:
#! /bin/sh
dir=$(pwd -P)
while [ -n "$dir" -a ! -f "$dir/$1" ]; do
dir=$dir%/*
done
if [ -f "$dir/$1" ]; then printf '%sn' "$dir/$1"; fi
Replace pwd -P
by pwd -L
if you want to follow symlinks instead of checking physical directories.
Any reason you use-a
?[ -n "$dir" ] && ! [ -f "$dir/$1" ]
is more reliable. (Exercise: Try determining correct parsing for[ -n "$a" -a "$b" = "$c" ]
ifa='='
andb='-o'
.)
– Wildcard
Jul 2 '16 at 5:19
@Wildcard Because I'm an old fart and set in my bad old ways. :) Also, because it avoids running a second[
on shells where[
is not a builtin. As for[ -n "$a" -a "$b" = "$c" ]
, that's why you always writex"$b" = x"$c"
rather than just"$b" = "$c"
.
– Satō Katsura
Jul 2 '16 at 5:30
add a comment |
One way to do it:
#! /bin/sh
dir=$(pwd -P)
while [ -n "$dir" -a ! -f "$dir/$1" ]; do
dir=$dir%/*
done
if [ -f "$dir/$1" ]; then printf '%sn' "$dir/$1"; fi
Replace pwd -P
by pwd -L
if you want to follow symlinks instead of checking physical directories.
One way to do it:
#! /bin/sh
dir=$(pwd -P)
while [ -n "$dir" -a ! -f "$dir/$1" ]; do
dir=$dir%/*
done
if [ -f "$dir/$1" ]; then printf '%sn' "$dir/$1"; fi
Replace pwd -P
by pwd -L
if you want to follow symlinks instead of checking physical directories.
answered Jul 2 '16 at 4:57
Satō KatsuraSatō Katsura
11k11634
11k11634
Any reason you use-a
?[ -n "$dir" ] && ! [ -f "$dir/$1" ]
is more reliable. (Exercise: Try determining correct parsing for[ -n "$a" -a "$b" = "$c" ]
ifa='='
andb='-o'
.)
– Wildcard
Jul 2 '16 at 5:19
@Wildcard Because I'm an old fart and set in my bad old ways. :) Also, because it avoids running a second[
on shells where[
is not a builtin. As for[ -n "$a" -a "$b" = "$c" ]
, that's why you always writex"$b" = x"$c"
rather than just"$b" = "$c"
.
– Satō Katsura
Jul 2 '16 at 5:30
add a comment |
Any reason you use-a
?[ -n "$dir" ] && ! [ -f "$dir/$1" ]
is more reliable. (Exercise: Try determining correct parsing for[ -n "$a" -a "$b" = "$c" ]
ifa='='
andb='-o'
.)
– Wildcard
Jul 2 '16 at 5:19
@Wildcard Because I'm an old fart and set in my bad old ways. :) Also, because it avoids running a second[
on shells where[
is not a builtin. As for[ -n "$a" -a "$b" = "$c" ]
, that's why you always writex"$b" = x"$c"
rather than just"$b" = "$c"
.
– Satō Katsura
Jul 2 '16 at 5:30
Any reason you use
-a
? [ -n "$dir" ] && ! [ -f "$dir/$1" ]
is more reliable. (Exercise: Try determining correct parsing for [ -n "$a" -a "$b" = "$c" ]
if a='='
and b='-o'
.)– Wildcard
Jul 2 '16 at 5:19
Any reason you use
-a
? [ -n "$dir" ] && ! [ -f "$dir/$1" ]
is more reliable. (Exercise: Try determining correct parsing for [ -n "$a" -a "$b" = "$c" ]
if a='='
and b='-o'
.)– Wildcard
Jul 2 '16 at 5:19
@Wildcard Because I'm an old fart and set in my bad old ways. :) Also, because it avoids running a second
[
on shells where [
is not a builtin. As for [ -n "$a" -a "$b" = "$c" ]
, that's why you always write x"$b" = x"$c"
rather than just "$b" = "$c"
.– Satō Katsura
Jul 2 '16 at 5:30
@Wildcard Because I'm an old fart and set in my bad old ways. :) Also, because it avoids running a second
[
on shells where [
is not a builtin. As for [ -n "$a" -a "$b" = "$c" ]
, that's why you always write x"$b" = x"$c"
rather than just "$b" = "$c"
.– Satō Katsura
Jul 2 '16 at 5:30
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f293393%2ffind-a-specific-file-in-the-nearest-ancestor-of-the-current-working-directory%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Do you also want this behavior of that node module? "If X/.dir/file.ext exists, return it." (that searches an immediate sub directory of X, not purely ancestors)
– Jeff Schaller
Jul 2 '16 at 14:27