On Fri, Mar 16, 2018 at 10:04:07AM +, Stormy wrote:
> Thanks for the confirmation regarding the need to write code. and also about
> 'cd' 'ls', yeah, it's what I sort of mean, bash does when passing args to
> them, but there is no other way to 'access' this type of parsing..
You are still qu
Date:Fri, 16 Mar 2018 10:04:07 + (UTC)
From:Stormy
Message-ID: <1098519022.1750755.1521194647...@mail.yahoo.com>
| however, both paths need to be normalized fully before
Yes, you're right, I did not consider that, but skipping empty
pathname components should b
Date:Thu, 15 Mar 2018 22:52:24 + (UTC)
From:Stormy
Message-ID: <68229887.1497301.1521154344...@mail.yahoo.com>
| but there is no way to make it do pathname matching internally. (cd, ls,
will surely do it,
No, they surely don't - the pathname expansion that yo
I think bash's echo does this, it doesn't do the pattern matching like
case, the slashes need to be there. You might need/want `shopt -s
dotglob nullglob`
Peter
On 03/16/2018 05:52 AM, Stormy wrote:
> ok, thanks for the confirmation. now u see what I meant before.. when saying
> bash does not h
ok, thanks for the confirmation. now u see what I meant before.. when saying
bash does not have a builtin way to call fnmatch (I meant: for path name
matching), clearly bash calls fnmatch, that is obvious, but there is no way to
make it do pathname matching internally. (cd, ls, will surely do i
On 3/15/18 3:26 PM, Stormy wrote:
> like I said, I've already implemented, roughly 40 lines in bash, and it
> seems to work, but if there is some builtin option 'shopt' or similar that
> can turn the right flags you mentioned, I'm all for testing it :)
There isn't. Pathname expansion is done in t
On 3/15/18 2:50 PM, Stormy wrote:
> Chet,
>
> ok, replacing 'pathname expansion' with 'pattern matching' is the right
> solution, otherwise u end up with a lot of confusing explanations :)
>
> if u think bash has builtin 'fnmatch' functionality, do u have an example
> clearly we see that 'case' a
On Thu, Mar 15, 2018 at 06:50:24PM +, Stormy wrote:
> if u think bash has builtin 'fnmatch' functionality, do u have an example?
echo *
On 3/15/18 12:15 PM, Stormy wrote:
> Thanks for the reply. I'm not sure we are talking about the same thing..
> maybe..does this example help?
> # case /test/test2/dir1/file in /test/*) echo 'match';; *) echo 'nomatch';;
> esac
> match
>
> here, the expectation is to NOT match, since '/test/*'
It is clear that the matching in 'case' does general pattern matching
but not pathname matching. I think the bash man page should say so,
clearly distinguishing different ways of matching in bash.
Peter
On 03/15/2018 11:15 PM, Stormy wrote:
> Thanks for the reply. I'm not sure we are talking ab
Thanks for the reply. I'm not sure we are talking about the same thing..
maybe..does this example help?
# case /test/test2/dir1/file in /test/*) echo 'match';; *) echo 'nomatch';;
esac
match
here, the expectation is to NOT match, since '/test/*' in normal shell, i.e.
"ls", would NOT match tha
On 3/14/18 1:43 PM, Stormy wrote:
> Bash Version: 4.2
> Patch Level: 46
> Release Status: release
>
> Description:
> Section of 'case' in bash's man page says:
>
> case word in [ [(] pattern [ | pattern ] ... ) list ;; ] ... esac
> A case command first expands word, and tries
12 matches
Mail list logo
