bash -c "cd '$1' && ls" -- ~/Desktop/ can't display the stuff on the target place.

[hongy...@gmail.com]

werner@X10DAi-00:~$ ls ~/Desktop/
Downloads.idm.wine "Newton's Principia for The Common Reader.djvu"
File.com.qq.weixin.deepin work
FileRecv.com.qq.im.deepin 霍金_时间简史.pdf

werner@X10DAi-00:~$ bash -c "cd '$1' && ls " -- ~/Desktop/
Desktop Mail PycharmProjects vmware
Documents Music README.md Yozo_Officelog.txt
Downloads News Templates Zotero
go Pictures texmf
hs_err_pid2195649.log Public Videos

werner@X10DAi-00:~$ bash -c "cd \$1 && ls " -- ~/Desktop/
Downloads.idm.wine "Newton's Principia for The Common Reader.djvu"
File.com.qq.weixin.deepin work
FileRecv.com.qq.im.deepin 霍金_时间简史.pdf

werner@X10DAi-00:~$ bash -c 'cd "$1" && ls' -- ~/Desktop/
Downloads.idm.wine "Newton's Principia for The Common Reader.djvu"
File.com.qq.weixin.deepin work
FileRecv.com.qq.im.deepin 霍金_时间简史.pdf

As you can see, the following two commands works as expected:

$ bash -c "cd \$1 && ls " -- ~/Desktop/
$ bash -c 'cd "$1" && ls' -- ~/Desktop/

But the following one doesn't:

$ bash -c "cd '$1' && ls " -- ~/Desktop/

Why does bash shell exhibit this behavior?

Regards,
HZ

[Janis Papanagnou]

On 04.12.2021 02:33, hongy...@gmail.com wrote:
>
> As you can see, the following two commands works as expected:

In my book, all work as expected.

>
> $ bash -c "cd \$1 && ls " -- ~/Desktop/
> $ bash -c 'cd "$1" && ls' -- ~/Desktop/
>
> But the following one doesn't:
>
> $ bash -c "cd '$1' && ls " -- ~/Desktop/
>
> Why does bash shell exhibit this behavior?

What behaviour; that $1 gets expanded on the outer shell level
[as expected]?

Because the expression passed to bash -c is double quoted and
thus variables like $1 will get expanded; the bash -c call
gets an expanded argument as parameter.

Why don't you try shell basics like shell quoting in simple
examples instead of trying to write complex shell programs?
It's so simple to check...

set wow
bash -c "echo '$1'"
bash -c "echo \$1"
bash -c 'echo "$1"'

Then what happens if you cd "" to an empty directory string?
That seems to depend on the shell. I think it should fail with
ENOENT (if I read POSIX correctly).

In any way you should avoid such potential errors by using the
correct quoting and guarantee the variables to get expanded as
intended.

Janis

>
> Regards,
> HZ
>

[hongy...@gmail.com]

On Saturday, December 4, 2021 at 10:17:58 AM UTC+8, Janis Papanagnou wrote:
> On 04.12.2021 02:33, hongy...@gmail.com wrote:
> >
> > As you can see, the following two commands works as expected:
> In my book, all work as expected.
> >
> > $ bash -c "cd \$1 && ls " -- ~/Desktop/
> > $ bash -c 'cd "$1" && ls' -- ~/Desktop/
> >
> > But the following one doesn't:
> >
> > $ bash -c "cd '$1' && ls " -- ~/Desktop/
> >
> > Why does bash shell exhibit this behavior?
> What behaviour; that $1 gets expanded on the outer shell level
> [as expected]?
>
> Because the expression passed to bash -c is double quoted and
> thus variables like $1 will get expanded; the bash -c call
> gets an expanded argument as parameter.
>
> Why don't you try shell basics like shell quoting in simple
> examples instead of trying to write complex shell programs?
> It's so simple to check...
>
> set wow
> bash -c "echo '$1'"
> bash -c "echo \$1"
> bash -c 'echo "$1"'

werner@X10DAi-00:~$ set wow
werner@X10DAi-00:~$ bash -c "echo '$1'"
wow
werner@X10DAi-00:~$ bash -c "echo \$1"

werner@X10DAi-00:~$ bash -c 'echo "$1"'

werner@X10DAi-00:~$

> Then what happens if you cd "" to an empty directory string?
> That seems to depend on the shell. I think it should fail with
> ENOENT (if I read POSIX correctly).

What do you mean by saying ENOENT?

[Kees Nuyt]

On Fri, 3 Dec 2021 19:33:50 -0800 (PST), "hongy...@gmail.com"
<hongy...@gmail.com> wrote:

> What do you mean by saying ENOENT?

Install the script named "ddg" below in a directory in your
path, and chmod +x /path/to/ddg ,
then type at the shell prompt:

$ ddg ENOENT

----- start of script ddg -----
#!/usr/bin/perl
#
# quickly search duck duck go from command line
#
# From: Eli the Bearded <*@eli.users.panix.com>
# Newsgroups: comp.misc
# Date: Mon, 12 Apr 2021 17:46:51 +0000 (UTC)

use strict;
use warnings;

my $browser = 'lynx';
my @browser_args = qw(
-useragent=Lynx/2.8.9rel.1
-image_links
-noreferer
-accept_all_cookies
-cookie_save_file=/dev/null
);
my $query = join('+',@ARGV);
my $base = 'https://duckduckgo.com/lite/';

if(defined($query) and $query ne '') {
$base .= "?q=$query";
}

push(@browser_args, $base);

exec($browser, @browser_args);
----- end of script ddg -----
--
Regards,
Kees Nuyt

[hongy...@gmail.com]

Thanks for your perl script. It basically means to open "https://duckduckgo.com/lite/" and search for "ENOENT". But I don't have much understanding of Perl's obscure syntax :-(

Anyway, I found the following explanation from here [1]:

It's an abbreviation of Error NO ENTry (or Error NO ENTity), and can actually be used for more than files/directories.

It's abbreviated because C compilers at the dawn of time didn't support more than 8 characters in symbols.

[1] https://stackoverflow.com/a/19902850

[Lew Pitcher]

You have put single-quotes around $1. This will cause
your shell to treat the contents literally, and NOT
expand $1.

HTH
--
Lew Pitcher
"In Skills, We Trust"

[Janis Papanagnou]

On 04.12.2021 04:33, hongy...@gmail.com wrote:
>
>> Then what happens if you cd "" to an empty directory string?
>> That seems to depend on the shell. I think it should fail with
>> ENOENT (if I read POSIX correctly).
>
> What do you mean by saying ENOENT?

It was a topical excursion to understand the 'cd' behavior in
the given application context.

By using various forms of quotes/escaped you had got your shell
variable expanded at different stages, effectively resulting in
getting a value or not. In the cases of not getting a value and
using it in context of the 'cd' command the question was how the
'cd' command would behave. Since you had used your command in a
conditional context cd "$arg" && some-cmd it's necessary to
know how cd "" would behave with an empty argument. Kornshell
would report an error ("cd: bad directory") and it seems Bash or
Zsh would not consider it an error but as a no-op. So I inspected
the POSIX specs, and it seemed to me that the given application
case would lead to and be reflected by the 'chdir()' Unix system
call; it should probably be passed back to the shell as an error.
For chdir(2) using an empty string argument the return is defined
as
[ENOENT]
A component of path does not name an existing directory or
path is an empty string.

Since shell's behaviors obviously seems to differ in case of an
empty cd argument the programmer has to take precaution to check
for empty arguments and handle that case appropriately. Or quote
correctly to avoid related bugs.

Janis

[Janis Papanagnou]

On 05.12.2021 09:40, Janis Papanagnou wrote:
> On 04.12.2021 04:33, hongy...@gmail.com wrote:
>>
>>> Then what happens if you cd "" to an empty directory string?
>>> That seems to depend on the shell. I think it should fail with
>>> ENOENT (if I read POSIX correctly).
>>
>> What do you mean by saying ENOENT?

In my explanations I forgot to mention that it is a standard
error code of Unix system calls. If chdir(2) is used by cd(1)
and chdir(2) produces that error code then cd(1) must handle
it in some (ideally standard-conformant) way. Read text below
with that in mind.

[hongy...@gmail.com]

On Saturday, December 4, 2021 at 10:17:58 AM UTC+8, Janis Papanagnou wrote:

> Then what happens if you cd "" to an empty directory string?
> That seems to depend on the shell. I think it should fail with
> ENOENT (if I read POSIX correctly).

See my following testing:

werner@X10DAi-00:~$ cd ""
werner@X10DAi-00:~$

[hongy...@gmail.com]

werner@X10DAi-00:~$ echo $SHELL
/bin/bash

[Janis Papanagnou]

On 06.12.2021 02:27, hongy...@gmail.com wrote:
> On Monday, December 6, 2021 at 9:23:13 AM UTC+8, hongy...@gmail.com wrote:
>> On Saturday, December 4, 2021 at 10:17:58 AM UTC+8, Janis Papanagnou wrote:
>>> Then what happens if you cd "" to an empty directory string?
>>> That seems to depend on the shell. I think it should fail with
>>> ENOENT (if I read POSIX correctly).
>> See my following testing:

Why shall I see it?

>> werner@X10DAi-00:~$ cd ""
>> werner@X10DAi-00:~$
>
> werner@X10DAi-00:~$ echo $SHELL
> /bin/bash

Yes, that's what I said in one of my posts here. Bash reports no error,
despite cd'ing to an non-existing ('ENOENT') directory.

All prominent shells don't change the directory when provided an empty
string. So if you use a conditional like cd "" && cmd Bash and Zsh
will execute the cmd despite the cd had no effect. In your case of a
cd "$undef_var" that might not be a very helpful behavior, but it's on
you to fix it by taking some measure that undef_var will get _defined_.

Janis

[David W. Hodgins]

On Sun, 05 Dec 2021 20:50:40 -0500, Janis Papanagnou <janis_pa...@hotmail.com> wrote:

> On 06.12.2021 02:27, hongy...@gmail.com wrote:
>> On Monday, December 6, 2021 at 9:23:13 AM UTC+8, hongy...@gmail.com wrote:
>>> On Saturday, December 4, 2021 at 10:17:58 AM UTC+8, Janis Papanagnou wrote:
>>>> Then what happens if you cd "" to an empty directory string?
>>>> That seems to depend on the shell. I think it should fail with
>>>> ENOENT (if I read POSIX correctly).
>>> See my following testing:
>
> Why shall I see it?
>
>>> werner@X10DAi-00:~$ cd ""
>>> werner@X10DAi-00:~$
>>
>> werner@X10DAi-00:~$ echo $SHELL
>> /bin/bash
>
> Yes, that's what I said in one of my posts here. Bash reports no error,
> despite cd'ing to an non-existing ('ENOENT') directory.

From "man bash"
cd [-L|[-P [-e]] [-@]] [dir]
Change the current directory to dir. if dir is not supplied, the value of the HOME shell variable is the default.

[dave@x3 Documents]$ pwd
/home/dave/Documents
[dave@x3 Documents]$ cd
[dave@x3 ~]$ pwd
/home/dave

[dave@x3 ~]$ grep dave /etc/passwd
dave:x:500:500:David W. Hodgins:/home/dave:/bin/bash

[dave@x3 ~]$ bash --version|head -n 1
GNU bash, version 5.1.4(1)-release (x86_64-mageia-linux-gnu)

Regards, Dave Hodgins

Regards, Dave Hodgins

[hongy...@gmail.com]

On Monday, December 6, 2021 at 10:48:57 AM UTC+8, David W. Hodgins wrote:
> On Sun, 05 Dec 2021 20:50:40 -0500, Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>
> > On 06.12.2021 02:27, hongy...@gmail.com wrote:
> >> On Monday, December 6, 2021 at 9:23:13 AM UTC+8, hongy...@gmail.com wrote:
> >>> On Saturday, December 4, 2021 at 10:17:58 AM UTC+8, Janis Papanagnou wrote:
> >>>> Then what happens if you cd "" to an empty directory string?
> >>>> That seems to depend on the shell. I think it should fail with
> >>>> ENOENT (if I read POSIX correctly).
> >>> See my following testing:
> >
> > Why shall I see it?
> >
> >>> werner@X10DAi-00:~$ cd ""
> >>> werner@X10DAi-00:~$
> >>
> >> werner@X10DAi-00:~$ echo $SHELL
> >> /bin/bash
> >
> > Yes, that's what I said in one of my posts here. Bash reports no error,
> > despite cd'ing to an non-existing ('ENOENT') directory.
> From "man bash"
> cd [-L|[-P [-e]] [-@]] [dir]
> Change the current directory to dir. if dir is not supplied, the value of the HOME shell variable is the default.

But if an empty string is supplied, NO-OP is the observed behavior for bash shell:

werner@X10DAi-00:~/Desktop$ pwd
/home/werner/Desktop
werner@X10DAi-00:~/Desktop$ cd ''
werner@X10DAi-00:~/Desktop$ pwd
/home/werner/Desktop
werner@X10DAi-00:~/Desktop$ cd ""
werner@X10DAi-00:~/Desktop$ pwd
/home/werner/Desktop

[David W. Hodgins]

Ah. Correct. A null variable is not the same as no variable and causes the cd
command to become a nop.

I agree that should be treated as an error rather then a nop.

Regards, Dave Hodgins

[Oğuz]

On Monday, December 6, 2021 at 6:46:04 AM UTC+3, David W. Hodgins wrote:
> Ah. Correct. A null variable is not the same as no variable and causes the cd
> command to become a nop.

Not really. See:

$ for sh in bash 'bash -o posix' bash-3.2.57 'bash-3.2.57 -o posix' bosh 'bosh -o posix' 'busybox sh' dash gwsh heirloom-sh ksh 'ksh -o posix' mksh 'mksh -o posix' 'mksh -o sh' oksh 'oksh -o posix' 'oksh -o sh' pdksh 'pdksh -o posix' posh yash 'yash -o posixly-correct' zsh 'zsh --emulate sh' 'zsh --emulate ksh'; do
> echo $sh
> $sh -c 'pwd; CDPATH=/ cd ""'
> echo
> done
bash
/home/oguz
/

bash -o posix
/home/oguz
/

bash-3.2.57
/home/oguz
/

bash-3.2.57 -o posix
/home/oguz
/

bosh
/home/oguz
bosh: null directory

bosh -o posix
/home/oguz
bosh: null directory

busybox sh
/home/oguz
//

dash
/home/oguz
//

gwsh
/home/oguz
gwsh: 1: cd: : No such file or directory

heirloom-sh
/home/oguz
heirloom-sh: null directory

ksh
/home/oguz
ksh: cd: bad directory

ksh -o posix
/home/oguz
ksh: cd: bad directory

mksh
/home/oguz
/

mksh -o posix
/home/oguz
/

mksh -o sh
/home/oguz
/

oksh
/home/oguz
/

oksh -o posix
/home/oguz
/

oksh -o sh
/home/oguz
/

pdksh
/home/oguz
/

pdksh -o posix
/home/oguz
/

posh
/home/oguz
/

yash
/home/oguz

yash -o posixly-correct
/home/oguz

zsh
/home/oguz

zsh --emulate sh
/home/oguz
/

zsh --emulate ksh
/home/oguz
/

$

>
> I agree that should be treated as an error rather then a nop.

I disagree; an empty string is a valid relative pathname. Shells above that error out/change pwd to `//' are broken.

>
> Regards, Dave Hodgins

[Janis Papanagnou]

On 06.12.2021 04:45, David W. Hodgins wrote:
>
> Ah. Correct. A null variable is not the same as no variable and causes
> the cd
> command to become a nop.
>
> I agree that should be treated as an error rather then a nop.

Well, the POSIX standard - after a very long procedural description
of what has to be done with directories in absolute or relative form,
given options -L and -P, given . and .., or with CDPATH specified or
not, and whatnot else - just specifies

"If directory is an empty string, the results are unspecified."

So I'd say that whatever outcome cd has given an empty string - whether
it appears to be sensible or inappropriate - is allowed by POSIX. (For
errors they say: "The working directory shall remain unchanged.")

Since files and directories have non-null names, specifying an empty
value I'd consider a programming-error that should be resulting in
an error that can be detected, caught and handled. (And, luckily, the
shell I practically prefer for many reasons does exactly that.)

The key (still) seems to be to specify a _non-empty_ directory argument
(by a correctly expanded and correctly quoted variable, if an argument
is provided that way).

Janis

[Chris Elvidge]

In bash, it also seems to depend on whether CDPATH is set or not.
With CDPATH unset, both cd "" and cd '' do not change the current
working directory (bash 5.1.12).
With CDPATH set, it seems to change to the first item in CDPATH.
(One reason I do not export CDPATH.)

(ksh gives an error, as you say.)


--
Chris Elvidge
England

[Keith Thompson]

Janis Papanagnou <janis_pa...@hotmail.com> writes:
[...]

> All prominent shells don't change the directory when provided an empty
> string. So if you use a conditional like cd "" && cmd Bash and Zsh
> will execute the cmd despite the cd had no effect. In your case of a
> cd "$undef_var" that might not be a very helpful behavior, but it's on
> you to fix it by taking some measure that undef_var will get _defined_.

csh, tcsh, and fish all report an error on "cd ''". (Not arguing
whether any of them are "prominent").

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[Keith Thompson]

Oğuz <oguzism...@gmail.com> writes:
[...]

> I disagree; an empty string is a valid relative pathname. Shells above
> that error out/change pwd to `//' are broken.

An interesting idea, but not one that's supported by POSIX.

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13
Pathname Resolution:

A null pathname shall not be successfully resolved.

[Janis Papanagnou]

On 06.12.2021 19:45, Keith Thompson wrote:
> Janis Papanagnou <janis_pa...@hotmail.com> writes:
> [...]
>> All prominent shells don't change the directory when provided an empty
>> string. So if you use a conditional like cd "" && cmd Bash and Zsh
>> will execute the cmd despite the cd had no effect. In your case of a
>> cd "$undef_var" that might not be a very helpful behavior, but it's on
>> you to fix it by taking some measure that undef_var will get _defined_.
>
> csh, tcsh, and fish all report an error on "cd ''". (Not arguing
> whether any of them are "prominent").

I used that word to sum up ksh, bash, and zsh, the powerful standard
shells typically used for programming, and in distinction to the
minimum feature shells like pure POSIX or Bourne shell, and also in
distinction to shells not (sensibly) suitable for programming like
the mentioned csh-based ones. That's the primary reason for using
the word "prominent", to specify a specific set (or class) of shells
that are suitable for comfortable programming and that have a POSIX
standard conforming base. (And I haven't found a better word for it.)

Janis

[Oğuz]

On Monday, December 6, 2021 at 10:44:30 PM UTC+3, Keith Thompson wrote:
> An interesting idea, but not one that's supported by POSIX.

I know,

>
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13
> Pathname Resolution:
>
> A null pathname shall not be successfully resolved.

but why? As a security measure?

[Helmut Waitzmann]

Oğuz <oguzism...@gmail.com>:

>I disagree; an empty string is a valid relative pathname. Shells
>above that error out/change pwd to `//' are broken.
>

Do you agree with the following statement?

If (read as shell command line syntax)

"${somedir}"

denotes a relative pathname that resolves to a directory, then if

"${somedir%/}"/subdir

resolves to a directory and does not resolve to a symbolic link to a
directory, then that directory should be a subdirectory of

"${somedir}"

and

"${somedir%/}"/subdir/..

should resolve to the same directory as

"${somedir}"

does.

Three examples:

First, define a shell function:

create_and_show_subdir_of()
(
# Do not exit on error:
set +e

set -- "${1?}" "${1%/}"/subdir "${1%/}"/subdir/.. &&

# "${1%/}" gives the value of the positional parameter
# no. 1 with a trailing slash (in case it's there)
# removed.

mkdir -- "$2" &&
{
if test "$1" -ef "$3"
then
format='%s\nand\n%s\nare the same.\n'
else
format='%s\nand\n%s\nare not the same.\n'
fi
ls -ldi -- "$@"
printf "$format" "$1" "$3"
rmdir -- "$2"
}
)

Then call that function using different parameters:

create_and_show_subdir_of 'a/relative/pathname'

create_and_show_subdir_of '.'

Now, try that function with the null pathname:

create_and_show_subdir_of ''

Do you see the inconsistency?


If "" (the empty pathname) ever should be a valid pathname, I would
vote for it to be the root directory, not the current working
directory.

See also the posting

Subject: Re: Why is "" (empty) not a valid file name?
From: Helmut Waitzmann <nn.th...@xoxy.net>
Newsgroups: comp.unix.shell
Date: Sat, 25 Apr 2020 01:30:18 +0200
Message-ID: <83r1wcf...@helmutwaitzmann.news.arcor.de>
References: <hgav4g...@mid.individual.net>
<83v9lqg...@helmutwaitzmann.news.arcor.de>
<hge7tu...@mid.individual.net>
<83sggug...@helmutwaitzmann.news.arcor.de>
<hgg69g...@mid.individual.net>

and its ancestor postings (Google might have archived them.  If not,
I can provide the contents of the posting.).

[Keith Thompson]

Helmut Waitzmann <nn.th...@xoxy.net> writes:
[...]

> If "" (the empty pathname) ever should be a valid pathname, I would
> vote for it to be the root directory, not the current working
> directory.

[...]

But then it would be in effect an absolute pathname even though it
doesn't start with a '/' character. I can see that causing more
problems.

[Helmut Waitzmann]

Keith Thompson <Keith.S.T...@gmail.com>:

>Helmut Waitzmann <nn.th...@xoxy.net> writes:
>[...]
>> If "" (the empty pathname) ever should be a valid pathname, I would
>> vote for it to be the root directory, not the current working
>> directory.
>[...]
>
>But then it would be in effect an absolute pathname even though it
>doesn't start with a '/' character.

Yes, but if viewed from a different direction that is not a problem:

The common rule to decide whether a pathname is an absolute or a
relative one is as follows:

If the first character of a pathname is a slash, the pathname is an
absolute one, else a relative one.

But one could imagine a different rule:

If the first character of a pathname is a character other than a
slash, the pathname is a relative one, else an absolute one.

If the following rule is added to restrict each of the two rules
above, then the two rule sets are equivalent:  If the pathname is
the empty path, then it is an invalid pathname.

I think, the fact that absolute pathnames start with a slash, is
only by coincidence.  The real cause of this coincidence can be
imagined as follows:

The (hidden) leading pathname component of the root directory is the
empty component.  The empty pathname is set to be an invalid
pathname.

The consequence of this is, that the root directory cannot be named
without a trailing slash.

Every pathname denoting a directory can be named with a trailing
slash, and that trailing slash does not hurt in any way.

The only difference where a trailing slash after a non‐empty
pathname makes a difference, is the case, where that pathname
denotes a symbolic link that refers to a directory.

But as the root directory will never be a symbolic link, forbidding
the empty pathname will cause no harm.

=> Absolute pathnames, i. e. pathnames starting with the root
directory, always begin with an empty pathname component followed by
a slash, which is textually the same as beginning with a slash.

>I can see that causing more problems.
>

Maybe that's the reason why the empty pathname has been defined to
be an invalid pathname.