Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #227180 > unrolled thread

weird behaviour of quotes in bash variable assignments

Back to article view | Back to linux.debian.user

Contents

  weird behaviour of quotes in bash variable assignments Gary Dale <gary@extremeground.com> - 2020-09-21 00:10 +0200
    Re: weird behaviour of quotes in bash variable assignments The Wanderer <wanderer@fastmail.fm> - 2020-09-21 00:20 +0200
      Re: weird behaviour of quotes in bash variable assignments David Christensen <dpchrist@holgerdanske.com> - 2020-09-21 02:40 +0200
        Re: weird behaviour of quotes in dash variable assignments Gary Dale <gary@extremeground.com> - 2020-09-21 03:20 +0200
          Re: weird behaviour of quotes in dash variable assignments David Christensen <dpchrist@holgerdanske.com> - 2020-09-21 05:00 +0200
            Re: weird behaviour of quotes in dash variable assignments Gary Dale <gary@extremeground.com> - 2020-09-21 06:00 +0200
              Re: weird behaviour of quotes in dash variable assignments David Christensen <dpchrist@holgerdanske.com> - 2020-09-21 06:20 +0200
          Re: weird behaviour of quotes in dash variable assignments David <bouncingcats@gmail.com> - 2020-09-21 05:40 +0200
            Re: weird behaviour of quotes in dash variable assignments David Christensen <dpchrist@holgerdanske.com> - 2020-09-21 06:10 +0200
              Re: weird behaviour of quotes in dash variable assignments Cindy Sue Causey <butterflybytes@gmail.com> - 2020-09-21 14:00 +0200
                Re: weird behaviour of quotes in dash variable assignments Greg Wooledge <wooledg@eeg.ccf.org> - 2020-09-21 14:20 +0200
                  Re: weird behaviour of quotes in dash variable assignments David Wright <deblis@lionunicorn.co.uk> - 2020-09-21 16:40 +0200
                    Re: weird behaviour of quotes in dash variable assignments Gary Dale <gary@extremeground.com> - 2020-09-22 03:00 +0200
                      Re: weird behaviour of quotes in dash variable assignments David Wright <deblis@lionunicorn.co.uk> - 2020-09-22 15:40 +0200
                        Re: weird behaviour of quotes in dash variable assignments Gary Dale <gary@extremeground.com> - 2020-09-22 19:40 +0200
                          Re: weird behaviour of quotes in dash variable assignments David Wright <deblis@lionunicorn.co.uk> - 2020-09-23 17:50 +0200
                  Re: weird behaviour of quotes in dash variable assignments Gary Dale <gary@extremeground.com> - 2020-09-21 18:40 +0200
                    Re: weird behaviour of quotes in dash variable assignments Greg Wooledge <wooledg@eeg.ccf.org> - 2020-09-21 18:50 +0200
                      Re: weird behaviour of quotes in dash variable assignments Gary Dale <gary@extremeground.com> - 2020-09-21 19:00 +0200
                        Re: weird behaviour of quotes in dash variable assignments Greg Wooledge <wooledg@eeg.ccf.org> - 2020-09-21 19:20 +0200
                          Re: weird behaviour of quotes in dash variable assignments Gary Dale <gary@extremeground.com> - 2020-09-21 20:50 +0200
                      Re: weird behaviour of quotes in dash variable assignments David Wright <deblis@lionunicorn.co.uk> - 2020-09-22 02:40 +0200
                    Re: weird behaviour of quotes in dash variable assignments David Christensen <dpchrist@holgerdanske.com> - 2020-09-21 22:20 +0200
                      Re: weird behaviour of quotes in dash variable assignments Gary Dale <gary@extremeground.com> - 2020-09-22 03:10 +0200
                        Re: weird behaviour of quotes in dash variable assignments David Christensen <dpchrist@holgerdanske.com> - 2020-09-22 06:30 +0200
                          Re: weird behaviour of quotes in dash variable assignments Gary Dale <gary@extremeground.com> - 2020-09-22 22:10 +0200
                            SSH agent forwarding (was: weird behaviour of quotes in dash variable  assignments) David Christensen <dpchrist@holgerdanske.com> - 2020-09-23 00:40 +0200
          Re: weird behaviour of quotes in dash variable assignments Greg Wooledge <wooledg@eeg.ccf.org> - 2020-09-21 14:00 +0200
            Re: weird behaviour of quotes in dash variable assignments Gary Dale <gary@extremeground.com> - 2020-09-21 18:40 +0200
      Re: weird behaviour of quotes in bash variable assignments Gary Dale <gary@extremeground.com> - 2020-09-21 03:10 +0200
    Re: weird behaviour of quotes in bash variable assignments <tomas@tuxteam.de> - 2020-09-21 10:00 +0200
      Re: weird behaviour of quotes in bash variable assignments David Christensen <dpchrist@holgerdanske.com> - 2020-09-21 22:20 +0200
        Re: weird behaviour of quotes in bash variable assignments Greg Wooledge <wooledg@eeg.ccf.org> - 2020-09-21 22:30 +0200
          Re: weird behaviour of quotes in bash variable assignments Gary Dale <gary@extremeground.com> - 2020-09-21 23:30 +0200
            Re: weird behaviour of quotes in bash variable assignments Andrei POPESCU <andreimpopescu@gmail.com> - 2020-09-22 07:50 +0200
              Re: weird behaviour of quotes in bash variable assignments Gary Dale <gary@extremeground.com> - 2020-09-22 22:40 +0200
                Re: weird behaviour of quotes in bash variable assignments Greg Wooledge <wooledg@eeg.ccf.org> - 2020-09-22 23:00 +0200
                Re: weird behaviour of quotes in bash variable assignments Andrei POPESCU <andreimpopescu@gmail.com> - 2020-09-23 12:00 +0200

Page 1 of 2  [1] 2  Next page →

#227180 — weird behaviour of quotes in bash variable assignments

I have the same bash script on two different Debian/Buster AMD64 
servers. However on one it refused to run. I tracked it down quickly to 
a variable substitution problem.

The line causing the problem reads: report="/root/clamscan-report"

On one server  echo $report  prints  /root/clamscan-report  while on the 
other it prints  "/root/clamscan-report".

Needless to say clamscan can't print to the latter. I fixed it by 
removing the quotes on the one server but now the scripts are different 
between the two servers, which isn't what I want. More importantly, I 
don't understand why it refuses to remove the quotes.

Where does this behaviour (keeping the quotes) get set?

[toc] | [next] | [standalone]

#227181

[Multipart message — attachments visible in raw view] — view raw

On 2020-09-20 at 17:27, Gary Dale wrote:

> I have the same bash script on two different Debian/Buster AMD64 
> servers. However on one it refused to run. I tracked it down quickly
> to a variable substitution problem.
> 
> The line causing the problem reads: report="/root/clamscan-report"
> 
> On one server  echo $report  prints  /root/clamscan-report  while on
> the other it prints  "/root/clamscan-report".
> 
> Needless to say clamscan can't print to the latter. I fixed it by 
> removing the quotes on the one server but now the scripts are
> different between the two servers, which isn't what I want.

Given the lack of spaces or other potentially-problematic characters in
the path, why not remove them on both servers? Will there potentially be
cases where the path is different, and such characters may be present?

> More importantly, I don't understand why it refuses to remove the
> quotes.
> 
> Where does this behaviour (keeping the quotes) get set?

First up: are you sure it's actually bash (rather than some other shell)
that's running the script in both cases?

Second, can you confirm that bash is the same version on both servers?
As reported by e.g 'bash --version'.

If both of those are confirmed, then it may be worth digging deeper. I'm
a bit reluctant to delve deep into the bash man page looking for
something like that without first ruling out other possibilities.

My first guess would be that one of the two might be using the shell
builtin command 'echo' and the other might be using /bin/echo, but
that's only a guess.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#227183

On 2020-09-20 15:14, The Wanderer wrote:
> On 2020-09-20 at 17:27, Gary Dale wrote:
> 
>> I have the same bash script on two different Debian/Buster AMD64
>> servers. However on one it refused to run. I tracked it down quickly
>> to a variable substitution problem.
>>
>> The line causing the problem reads: report="/root/clamscan-report"
>>
>> On one server  echo $report  prints  /root/clamscan-report  while on
>> the other it prints  "/root/clamscan-report".
>>
>> Needless to say clamscan can't print to the latter. I fixed it by
>> removing the quotes on the one server but now the scripts are
>> different between the two servers, which isn't what I want.
> 
> Given the lack of spaces or other potentially-problematic characters in
> the path, why not remove them on both servers? Will there potentially be
> cases where the path is different, and such characters may be present?
> 
>> More importantly, I don't understand why it refuses to remove the
>> quotes.
>>
>> Where does this behaviour (keeping the quotes) get set?
> 
> First up: are you sure it's actually bash (rather than some other shell)
> that's running the script in both cases?
> 
> Second, can you confirm that bash is the same version on both servers?
> As reported by e.g 'bash --version'.
> 
> If both of those are confirmed, then it may be worth digging deeper. I'm
> a bit reluctant to delve deep into the bash man page looking for
> something like that without first ruling out other possibilities.
> 
> My first guess would be that one of the two might be using the shell
> builtin command 'echo' and the other might be using /bin/echo, but
> that's only a guess.

And:


Is the environment identical on the two servers?

     server1$ env > env1.out

     server2$ env > env2.out

     (move one file to the other host)

     $ diff env1.out env2.out


Do you have a  "shebang" line as the first line of the script?  Please post.


I find that Bourne syntax shell scripts are more portable than Bash 
syntax shell scripts.  Have you tried '#!/bin/sh' ?


Have you tried single quotes?


David

[toc] | [prev] | [next] | [standalone]

#227185 — Re: weird behaviour of quotes in dash variable assignments

On 2020-09-20 20:36, David Christensen wrote:
> On 2020-09-20 15:14, The Wanderer wrote:
>> On 2020-09-20 at 17:27, Gary Dale wrote:
>>
>>> I have the same bash script on two different Debian/Buster AMD64
>>> servers. However on one it refused to run. I tracked it down quickly
>>> to a variable substitution problem.
>>>
>>> The line causing the problem reads: report="/root/clamscan-report"
>>>
>>> On one server  echo $report  prints  /root/clamscan-report while on
>>> the other it prints  "/root/clamscan-report".
>>>
>>> Needless to say clamscan can't print to the latter. I fixed it by
>>> removing the quotes on the one server but now the scripts are
>>> different between the two servers, which isn't what I want.
>>
>> Given the lack of spaces or other potentially-problematic characters in
>> the path, why not remove them on both servers? Will there potentially be
>> cases where the path is different, and such characters may be present?
>>
>>> More importantly, I don't understand why it refuses to remove the
>>> quotes.
>>>
>>> Where does this behaviour (keeping the quotes) get set?
>>
>> First up: are you sure it's actually bash (rather than some other shell)
>> that's running the script in both cases?
>>
>> Second, can you confirm that bash is the same version on both servers?
>> As reported by e.g 'bash --version'.
>>
>> If both of those are confirmed, then it may be worth digging deeper. I'm
>> a bit reluctant to delve deep into the bash man page looking for
>> something like that without first ruling out other possibilities.
>>
>> My first guess would be that one of the two might be using the shell
>> builtin command 'echo' and the other might be using /bin/echo, but
>> that's only a guess.
>
> And:
>
>
> Is the environment identical on the two servers?
>
>     server1$ env > env1.out
>
>     server2$ env > env2.out
>
>     (move one file to the other host)
>
>     $ diff env1.out env2.out


The environments are identical. The server uses are similar - both run 
Samba 4 and have Exim 4 set up for sending mail to me. Both run KVM 
virtual machines. The server that works also runs bacula and borg while 
the problem server runs NFS and Apache2.


>
>
> Do you have a  "shebang" line as the first line of the script? Please 
> post.
>
>
> I find that Bourne syntax shell scripts are more portable than Bash 
> syntax shell scripts.  Have you tried '#!/bin/sh' ?

That's my shebang line. /bin/sh in both cases is a symlink to dash 
(sorry, keep forgetting that Debian has been using dash instead of bash 
for years now). The version of dash is identical between the two servers.


>
>
> Have you tried single quotes?

Wouldn't want to. Single quotes alter the behaviour.

[toc] | [prev] | [next] | [standalone]

#227187 — Re: weird behaviour of quotes in dash variable assignments

On 2020-09-20 18:18, Gary Dale wrote:
> On 2020-09-20 20:36, David Christensen wrote:

> The environments are identical.

>> Have you tried '#!/bin/sh' ?
> 
> That's my shebang line.

>> Have you tried single quotes?
> 
> Wouldn't want to. Single quotes alter the behaviour.

Double quotes, single quotes, and no quotes have the same behavior on my 
machine:

2020-09-20 19:50:55 dpchrist@tinkywinky ~/sandbox/sh
$ cat debian-user-20200920-1727-gary-dale.sh
#!/bin/sh

doublequote="/root/clamscan-report"
echo $doublequote

singlequote='/root/clamscan-report'
echo $singlequote

noquote='/root/clamscan-report'
echo $noquote

2020-09-20 19:53:02 dpchrist@tinkywinky ~/sandbox/sh
$ /bin/sh -x debian-user-20200920-1727-gary-dale.sh
+ doublequote=/root/clamscan-report
+ echo /root/clamscan-report
/root/clamscan-report
+ singlequote=/root/clamscan-report
+ echo /root/clamscan-report
/root/clamscan-report
+ noquote=/root/clamscan-report
+ echo /root/clamscan-report
/root/clamscan-report


Please run the above script and the following commands, and post your 
console session -- prompts, commands, output:

2020-09-20 19:52:29 dpchrist@tinkywinky ~/sandbox/sh
$ cat /etc/debian_version
9.13

2020-09-20 19:52:38 dpchrist@tinkywinky ~/sandbox/sh
$ uname -a
Linux tinkywinky 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05) 
x86_64 GNU/Linux

2020-09-20 19:52:43 dpchrist@tinkywinky ~/sandbox/sh
$ dpkg-query --show dash
dash	0.5.8-2.4

2020-09-20 19:52:51 dpchrist@tinkywinky ~/sandbox/sh
$ dpkg --verify dash

2020-09-20 19:52:56 dpchrist@tinkywinky ~/sandbox/sh
$ sha256sum /bin/sh
e803088e7938b328b0511957dcd0dd7b5600ec1940010c64dbd3814e3d75495f  /bin/sh


David

[toc] | [prev] | [next] | [standalone]

#227190 — Re: weird behaviour of quotes in dash variable assignments

On 2020-09-20 22:55, David Christensen wrote:
> On 2020-09-20 18:18, Gary Dale wrote:
>> On 2020-09-20 20:36, David Christensen wrote:
>
>> The environments are identical.
>
>>> Have you tried '#!/bin/sh' ?
>>
>> That's my shebang line.
>
>>> Have you tried single quotes?
>>
>> Wouldn't want to. Single quotes alter the behaviour.
>
> Double quotes, single quotes, and no quotes have the same behavior on 
> my machine:
>
> 2020-09-20 19:50:55 dpchrist@tinkywinky ~/sandbox/sh
> $ cat debian-user-20200920-1727-gary-dale.sh
> #!/bin/sh
>
> doublequote="/root/clamscan-report"
> echo $doublequote
>
> singlequote='/root/clamscan-report'
> echo $singlequote
>
> noquote='/root/clamscan-report'
> echo $noquote
>
> 2020-09-20 19:53:02 dpchrist@tinkywinky ~/sandbox/sh
> $ /bin/sh -x debian-user-20200920-1727-gary-dale.sh
> + doublequote=/root/clamscan-report
> + echo /root/clamscan-report
> /root/clamscan-report
> + singlequote=/root/clamscan-report
> + echo /root/clamscan-report
> /root/clamscan-report
> + noquote=/root/clamscan-report
> + echo /root/clamscan-report
> /root/clamscan-report
>
>
> Please run the above script and the following commands, and post your 
> console session -- prompts, commands, output:
>
> 2020-09-20 19:52:29 dpchrist@tinkywinky ~/sandbox/sh
> $ cat /etc/debian_version
> 9.13
>
> 2020-09-20 19:52:38 dpchrist@tinkywinky ~/sandbox/sh
> $ uname -a
> Linux tinkywinky 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05) 
> x86_64 GNU/Linux
>
> 2020-09-20 19:52:43 dpchrist@tinkywinky ~/sandbox/sh
> $ dpkg-query --show dash
> dash    0.5.8-2.4
>
> 2020-09-20 19:52:51 dpchrist@tinkywinky ~/sandbox/sh
> $ dpkg --verify dash
>
> 2020-09-20 19:52:56 dpchrist@tinkywinky ~/sandbox/sh
> $ sha256sum /bin/sh
> e803088e7938b328b0511957dcd0dd7b5600ec1940010c64dbd3814e3d75495f /bin/sh
>
>
> David
>
In the simple case, the quotes are the same, but there are times when 
they have different behaviours. I avoid single-quotes so that when I use 
them, it's a clue that there is a reason.

Here's what I got with your script:

/root/clamscan-report
/root/clamscan-report
/root/clamscan-report

When I retried my script with the quotes, it started working. I have no 
idea what changed from earlier today. I certainly didn't update anything 
on either server...

[toc] | [prev] | [next] | [standalone]

#227192 — Re: weird behaviour of quotes in dash variable assignments

On 2020-09-20 20:52, Gary Dale wrote:
> On 2020-09-20 22:55, David Christensen wrote:

>> 2020-09-20 19:50:55 dpchrist@tinkywinky ~/sandbox/sh
>> $ cat debian-user-20200920-1727-gary-dale.sh
>> #!/bin/sh
>>
>> doublequote="/root/clamscan-report"
>> echo $doublequote
>>
>> singlequote='/root/clamscan-report'
>> echo $singlequote
>>
>> noquote='/root/clamscan-report'
>> echo $noquote
>>
>> 2020-09-20 19:53:02 dpchrist@tinkywinky ~/sandbox/sh
>> $ /bin/sh -x debian-user-20200920-1727-gary-dale.sh
>> + doublequote=/root/clamscan-report
>> + echo /root/clamscan-report
>> /root/clamscan-report
>> + singlequote=/root/clamscan-report
>> + echo /root/clamscan-report
>> /root/clamscan-report
>> + noquote=/root/clamscan-report
>> + echo /root/clamscan-report
>> /root/clamscan-report

> In the simple case, the quotes are the same, but there are times when 
> they have different behaviours. I avoid single-quotes so that when I use 
> them, it's a clue that there is a reason.

AIUI the Bourne shell interpolates variables, and potentially other 
constructs, within double-quotes.  I avoid double quotes unless I want 
interpolation.


> Here's what I got with your script:
> 
> /root/clamscan-report
> /root/clamscan-report
> /root/clamscan-report
> 
> When I retried my script with the quotes, it started working. I have no 
> idea what changed from earlier today. I certainly didn't update anything 
> on either server...

I find that a version control system can be very useful for system 
administration, by allowing me to check in and verify all of my 
configuration files, scripts, etc..


David

[toc] | [prev] | [next] | [standalone]

#227188 — Re: weird behaviour of quotes in dash variable assignments

On Mon, 21 Sep 2020 at 11:18, Gary Dale <gary@extremeground.com> wrote:

> >>> I have the same bash script on two different Debian/Buster AMD64
> >>> servers. However on one it refused to run. I tracked it down quickly
> >>> to a variable substitution problem.

> >>> The line causing the problem reads: report="/root/clamscan-report"

> >>> On one server  echo $report  prints  /root/clamscan-report while on
> >>> the other it prints  "/root/clamscan-report".

The shell should strip the double quotes before assigning the right hand
string to the left hand variable.

Another possibility to check that I haven't seen suggested already, even
if it is unlikely ...

>From the perspective of not knowing how these bash scripts were deployed,
it's worth confirming that what we are assuming is the "same bash script" are
indeed exactly identical.

$ cmp script1 script2

If somehow the double quotes in the problem script have become something
other than plain ASCII 0x22 bytes, that could explain the observed behaviour.
Because extended character sets can contain a variety of characters that
visually appear identical to their plain ASCII counterparts. But the shell won't
parse and remove them as quote characters, even though they "look like" quote
characters.

[toc] | [prev] | [next] | [standalone]

#227191 — Re: weird behaviour of quotes in dash variable assignments

On 2020-09-20 20:38, David wrote:

> From the perspective of not knowing how these bash scripts were deployed,
> it's worth confirming that what we are assuming is the "same bash script" are
> indeed exactly identical.
> 
> $ cmp script1 script2
> 
> If somehow the double quotes in the problem script have become something
> other than plain ASCII 0x22 bytes, that could explain the observed behaviour.
> Because extended character sets can contain a variety of characters that
> visually appear identical to their plain ASCII counterparts. But the shell won't
> parse and remove them as quote characters, even though they "look like" quote
> characters.

A spurious space character at the end of the line is invisible in most 
editors, but can cause problems for some programs.  For other programs, 
spaces at the end of a line have meaning (e.g. Markdown).  Similarly, 
leading or interior spaces vs. tab will drive you mad (e.g. Make). 
Without the files and the servers they run on, we can only speculate.


David

[toc] | [prev] | [next] | [standalone]

#227205 — Re: weird behaviour of quotes in dash variable assignments

On 9/21/20, David Christensen <dpchrist@holgerdanske.com> wrote:
> On 2020-09-20 20:38, David wrote:
>
>> From the perspective of not knowing how these bash scripts were deployed,
>> it's worth confirming that what we are assuming is the "same bash script"
>> are
>> indeed exactly identical.
>>
>> $ cmp script1 script2
>>
>> If somehow the double quotes in the problem script have become something
>> other than plain ASCII 0x22 bytes, that could explain the observed
>> behaviour.
>> Because extended character sets can contain a variety of characters that
>> visually appear identical to their plain ASCII counterparts. But the shell
>> won't
>> parse and remove them as quote characters, even though they "look like"
>> quote
>> characters.
>
> A spurious space character at the end of the line is invisible in most
> editors, but can cause problems for some programs.  For other programs,
> spaces at the end of a line have meaning (e.g. Markdown).  Similarly,
> leading or interior spaces vs. tab will drive you mad (e.g. Make).


Oh, yeah! I don't remember how long I fought this when I first started
playing with web design. They're invisible except under circumstances.
I accidentally FINALLY figured it out when I had opened a file up in a
super plain text editor that wasn't.. MS Word.

There was something like a one or two-character blob in the first line
that was keeping the file from displaying properly in about the only
browser that existed back then AND was also keeping it from validating
properly (via W3 dotORG).


> Without the files and the servers they run on, we can only speculate.


Thought about writing this yesterday then it looked like things might
have been solved or suchly. Since this is still being chatted up...

Another much more recent fix for me has been to delete the quotes, and
I think also apostrophes, and simply retype them (instead of
copy-and-paste).

If that has already been done since this was about that one line,
maybe it's about something similar in a line prior to that one. With a
head nod to what's typed below, try the same for ALL apostrophes, too.

It's that same deal about things being "invisible" until they're
displayed in the right text editor kind of package. There's quotes,
and there's fancy quotes. A quick search pumped out Wikipedia [0]:

'…' and "…" are known as neutral, vertical, straight, typewriter,
dumb, or ASCII quotation marks.

‘…’ and “…” are known as typographic, curly, curved, book, or smart
quotation marks.

Those lines from Wikipedia may print out the same in this method of
sharing. If they do, the second set are visually "curlier" than the
first. Wikipedia goes on to say the second set are for manuscripts,
printing, and typesetting.

My take: It's like the second "curly, curved" set envelopes, leans
into, visually gets cozier with the enclosed text a tiny bit more.

Both types of quotation marks frequently look ALMOST exactly the same
unless you have them blown up in an extra large font size on the
screen.

They function differently somehow, too. I don't remember if that
difference in functioning was by design or just bad placement in a
file. Maybe it's about the above reference to ASCII. Discovering the
difference between them was another one of those ah-ha moments tripped
over via a terminal window.

May or may not help, but you could try "editor <file>" to see if
anything odd shows up that way. I just did so with both mousepad and
editor (terminal) for the (.)Xauthority file.

Mousepad kicks out a "The file was not UTF-8 valid" error and aborts.
Editor in the terminal at least displays a bunch of characters that
include a number of question marks filling in for whatever part of
that is causing mousepad to fail. Not a great apples to apples
example, but it's the best I can think of just now.

Happy Monday morning..

Cindy :)

[0] https://en.wikipedia.org/wiki/Quotation_mark
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

[toc] | [prev] | [next] | [standalone]

#227206 — Re: weird behaviour of quotes in dash variable assignments

On Mon, Sep 21, 2020 at 07:55:45AM -0400, Cindy Sue Causey wrote:
> '…' and "…" are known as neutral, vertical, straight, typewriter,
> dumb, or ASCII quotation marks.
> 
> ‘…’ and “…” are known as typographic, curly, curved, book, or smart
> quotation marks.

Yes.  This is one of the possible causes for the behavior the OP was
reporting.  But if this is true, then it reveals that they were lying
when they claimed that the scripts were the same on both servers.

> They function differently somehow, too. I don't remember if that
> difference in functioning was by design or just bad placement in a
> file. Maybe it's about the above reference to ASCII. Discovering the
> difference between them was another one of those ah-ha moments tripped
> over via a terminal window.

Remember, the computer can't actually *see* the characters the way
that you do.  To the computer, every character is just a number, or
a sequence of numbers.

To bash, the character " (byte value 0x22) has a special meaning, and
so does the character ' (byte value 0x27).  However, the characters
“ (byte values 0xe2809c) and ” (byte values 0xe2809d) have no special
meaning.  They're just some random data that the shell doesn't interpret.

unicorn:~$ x="foo"; echo "$x"
foo
unicorn:~$ x='foo'; echo "$x"
foo
unicorn:~$ x=“foo”; echo "$x"
“foo”

To beat a dead horse some more, if *this* was the OP's problem, then they
told multiple lies about it.  They did not paste the actual failing line
from the failing script (probably retyped it instead), and they did not
ACTUALLY COMPARE the two scripts to see whether they were different,
instead simply ASSUMING that the two scripts were identical, even though
they very clearly weren't.

An actual troubleshooting would have done something like using md5sum
on the script on each machine, and pasting the md5sum commands (including
the full script pathname) and their output to the mailing list.  Openness.

Or, hell, even "ls -l /full/pathname" would probably have revealed that
the scripts were not the same SIZE.  That would also have shown immediately
that the scripts were not "the same".

[toc] | [prev] | [next] | [standalone]

#227211 — Re: weird behaviour of quotes in dash variable assignments

On Mon 21 Sep 2020 at 08:18:52 (-0400), Greg Wooledge wrote:
> On Mon, Sep 21, 2020 at 07:55:45AM -0400, Cindy Sue Causey wrote:
> > '…' and "…" are known as neutral, vertical, straight, typewriter,
> > dumb, or ASCII quotation marks.
> > 
> > ‘…’ and “…” are known as typographic, curly, curved, book, or smart
> > quotation marks.
> 
> Yes.  This is one of the possible causes for the behavior the OP was
> reporting.  But if this is true, then it reveals that they were lying
> when they claimed that the scripts were the same on both servers.
>
> […]
> 
> To beat a dead horse some more, if *this* was the OP's problem, then they
> told multiple lies about it.  They did not paste the actual failing line
> from the failing script (probably retyped it instead), and they did not
> ACTUALLY COMPARE the two scripts to see whether they were different,
> instead simply ASSUMING that the two scripts were identical, even though
> they very clearly weren't.
> 
> An actual troubleshooting would have done something like using md5sum
> on the script on each machine, and pasting the md5sum commands (including
> the full script pathname) and their output to the mailing list.  Openness.
> 
> Or, hell, even "ls -l /full/pathname" would probably have revealed that
> the scripts were not the same SIZE.  That would also have shown immediately
> that the scripts were not "the same".

I think we should apply Hanlon's razor rather than saying the OP lied.
After all, "compare" means diff or cmp to us, whereas many might just
use their eyeballs. And we all know that authors are the worst people
to check their own work. Proof-reading is a special skill.

Even their fix is poorly described. Did they just type the quotes back
in with an editor, in which case there's no guarantee that the scripts
are identical between machines, or did they transfer a working script
to the failing machine? The best line is save until last: "I certainly
didn't update anything on either server...". Well, yes, that's
*precisely* what you did: you updated the script.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#227232 — Re: weird behaviour of quotes in dash variable assignments

On 2020-09-21 10:30, David Wright wrote:
> On Mon 21 Sep 2020 at 08:18:52 (-0400), Greg Wooledge wrote:
>> On Mon, Sep 21, 2020 at 07:55:45AM -0400, Cindy Sue Causey wrote:
>>> '…' and "…" are known as neutral, vertical, straight, typewriter,
>>> dumb, or ASCII quotation marks.
>>>
>>> ‘…’ and “…” are known as typographic, curly, curved, book, or smart
>>> quotation marks.
>> Yes.  This is one of the possible causes for the behavior the OP was
>> reporting.  But if this is true, then it reveals that they were lying
>> when they claimed that the scripts were the same on both servers.
>>
>> […]
>>
>> To beat a dead horse some more, if *this* was the OP's problem, then they
>> told multiple lies about it.  They did not paste the actual failing line
>> from the failing script (probably retyped it instead), and they did not
>> ACTUALLY COMPARE the two scripts to see whether they were different,
>> instead simply ASSUMING that the two scripts were identical, even though
>> they very clearly weren't.
>>
>> An actual troubleshooting would have done something like using md5sum
>> on the script on each machine, and pasting the md5sum commands (including
>> the full script pathname) and their output to the mailing list.  Openness.
>>
>> Or, hell, even "ls -l /full/pathname" would probably have revealed that
>> the scripts were not the same SIZE.  That would also have shown immediately
>> that the scripts were not "the same".
> I think we should apply Hanlon's razor rather than saying the OP lied.
> After all, "compare" means diff or cmp to us, whereas many might just
> use their eyeballs. And we all know that authors are the worst people
> to check their own work. Proof-reading is a special skill.
>
> Even their fix is poorly described. Did they just type the quotes back
> in with an editor, in which case there's no guarantee that the scripts
> are identical between machines, or did they transfer a working script
> to the failing machine? The best line is save until last: "I certainly
> didn't update anything on either server...". Well, yes, that's
> *precisely* what you did: you updated the script.
>
> Cheers,
> David.
>
You are taking my quote out of context. I didn't change anything on the 
server to make the script start working. I updated the script to see if 
it would work after trying Greg's test. There were no program or setting 
updates on the server, and certainly nothing that updated dash. This is 
Debian/Stable we're talking about, after all.

Since it is a file server, there probably were changes to the files on 
its shares, but I'd hardly count that as an "update". Similarly, it was 
running cron jobs for backups and virus scans (unsuccessfully) but again 
I wouldn't call those "updates".

[toc] | [prev] | [next] | [standalone]

#227248 — Re: weird behaviour of quotes in dash variable assignments

On Mon 21 Sep 2020 at 20:50:29 (-0400), Gary Dale wrote:
> On 2020-09-21 10:30, David Wright wrote:
> > On Mon 21 Sep 2020 at 08:18:52 (-0400), Greg Wooledge wrote:
> > > On Mon, Sep 21, 2020 at 07:55:45AM -0400, Cindy Sue Causey wrote:
> > > > '…' and "…" are known as neutral, vertical, straight, typewriter,
> > > > dumb, or ASCII quotation marks.
> > > > 
> > > > ‘…’ and “…” are known as typographic, curly, curved, book, or smart
> > > > quotation marks.
> > > Yes.  This is one of the possible causes for the behavior the OP was
> > > reporting.  But if this is true, then it reveals that they were lying
> > > when they claimed that the scripts were the same on both servers.
> > > 
> > > […]
> > > 
> > > To beat a dead horse some more, if *this* was the OP's problem, then they
> > > told multiple lies about it.  They did not paste the actual failing line
> > > from the failing script (probably retyped it instead), and they did not
> > > ACTUALLY COMPARE the two scripts to see whether they were different,
> > > instead simply ASSUMING that the two scripts were identical, even though
> > > they very clearly weren't.
> > > 
> > > An actual troubleshooting would have done something like using md5sum
> > > on the script on each machine, and pasting the md5sum commands (including
> > > the full script pathname) and their output to the mailing list.  Openness.
> > > 
> > > Or, hell, even "ls -l /full/pathname" would probably have revealed that
> > > the scripts were not the same SIZE.  That would also have shown immediately
> > > that the scripts were not "the same".
> > I think we should apply Hanlon's razor rather than saying the OP lied.
> > After all, "compare" means diff or cmp to us, whereas many might just
> > use their eyeballs. And we all know that authors are the worst people
> > to check their own work. Proof-reading is a special skill.
> > 
> > Even their fix is poorly described. Did they just type the quotes back
> > in with an editor, in which case there's no guarantee that the scripts
> > are identical between machines, or did they transfer a working script
> > to the failing machine? The best line is save until last: "I certainly
> > didn't update anything on either server...". Well, yes, that's
> > *precisely* what you did: you updated the script.
                              ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
> > 
> You are taking my quote out of context. I didn't change anything on
> the server to make the script start working. I updated the script to
                                               ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
> see if it would work after trying Greg's test. There were no program
> or setting updates on the server, and certainly nothing that updated
> dash. This is Debian/Stable we're talking about, after all.

Sorry, I thought you wrote that on Sunday afternoon, "I fixed it by
removing the quotes on the one server but now the scripts are
different between the two servers, which isn't what I want."
Then on Sunday evening, you wrote "When I retried my script with the
quotes, it started working."

The general opinion is that the script was faulty, probably in the
quotes used. The narrative says that you removed the quotes, and
later put them back. It seems fair to suggest that the quotes you
put back were not the same ones that you removed. They were replaced
in the same location, but you didn't put the old (removed) quotes
into a little two-character file, so that you could put precisely
the same ones back into the script, did you?

> Since it is a file server, there probably were changes to the files on
> its shares, but I'd hardly count that as an "update". Similarly, it
> was running cron jobs for backups and virus scans (unsuccessfully) but
> again I wouldn't call those "updates".

Nor I. No, I'm only talking about your script. Does it bear any
relation to the one posted in your blog? The first line (after
the shebang) of the one in the blog is the same line that's under
discussion here, and has curly quotes. I can't parse the second
line's curly quotes, and the fourth line uses an n-dash for a
hyphen *though the other hyphens are ok). The fifth line uses
curly single-quotes. More curly quotes follow.

I don't see any cause for our wasting time pondering on dash
without your posting an MWE that unambiguously demonstrates a
problem.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#227253 — Re: weird behaviour of quotes in dash variable assignments

On 2020-09-22 09:29, David Wright wrote:
> On Mon 21 Sep 2020 at 20:50:29 (-0400), Gary Dale wrote:
>> On 2020-09-21 10:30, David Wright wrote:
>>> On Mon 21 Sep 2020 at 08:18:52 (-0400), Greg Wooledge wrote:
>>>> On Mon, Sep 21, 2020 at 07:55:45AM -0400, Cindy Sue Causey wrote:
>>>>> '…' and "…" are known as neutral, vertical, straight, typewriter,
>>>>> dumb, or ASCII quotation marks.
>>>>>
>>>>> ‘…’ and “…” are known as typographic, curly, curved, book, or smart
>>>>> quotation marks.
>>>> Yes.  This is one of the possible causes for the behavior the OP was
>>>> reporting.  But if this is true, then it reveals that they were lying
>>>> when they claimed that the scripts were the same on both servers.
>>>>
>>>> […]
>>>>
>>>> To beat a dead horse some more, if *this* was the OP's problem, then they
>>>> told multiple lies about it.  They did not paste the actual failing line
>>>> from the failing script (probably retyped it instead), and they did not
>>>> ACTUALLY COMPARE the two scripts to see whether they were different,
>>>> instead simply ASSUMING that the two scripts were identical, even though
>>>> they very clearly weren't.
>>>>
>>>> An actual troubleshooting would have done something like using md5sum
>>>> on the script on each machine, and pasting the md5sum commands (including
>>>> the full script pathname) and their output to the mailing list.  Openness.
>>>>
>>>> Or, hell, even "ls -l /full/pathname" would probably have revealed that
>>>> the scripts were not the same SIZE.  That would also have shown immediately
>>>> that the scripts were not "the same".
>>> I think we should apply Hanlon's razor rather than saying the OP lied.
>>> After all, "compare" means diff or cmp to us, whereas many might just
>>> use their eyeballs. And we all know that authors are the worst people
>>> to check their own work. Proof-reading is a special skill.
>>>
>>> Even their fix is poorly described. Did they just type the quotes back
>>> in with an editor, in which case there's no guarantee that the scripts
>>> are identical between machines, or did they transfer a working script
>>> to the failing machine? The best line is save until last: "I certainly
>>> didn't update anything on either server...". Well, yes, that's
>>> *precisely* what you did: you updated the script.
>                                ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
>> You are taking my quote out of context. I didn't change anything on
>> the server to make the script start working. I updated the script to
>                                                 ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
>> see if it would work after trying Greg's test. There were no program
>> or setting updates on the server, and certainly nothing that updated
>> dash. This is Debian/Stable we're talking about, after all.
> Sorry, I thought you wrote that on Sunday afternoon, "I fixed it by
> removing the quotes on the one server but now the scripts are
> different between the two servers, which isn't what I want."
> Then on Sunday evening, you wrote "When I retried my script with the
> quotes, it started working."
>
> The general opinion is that the script was faulty, probably in the
> quotes used. The narrative says that you removed the quotes, and
> later put them back. It seems fair to suggest that the quotes you
> put back were not the same ones that you removed. They were replaced
> in the same location, but you didn't put the old (removed) quotes
> into a little two-character file, so that you could put precisely
> the same ones back into the script, did you?
I thought about that but then there would be no way I could demonstrate 
it other than what I did - post the offending line via cut & paste, a 
method people have been arguing can change the quotes.
>
>> Since it is a file server, there probably were changes to the files on
>> its shares, but I'd hardly count that as an "update". Similarly, it
>> was running cron jobs for backups and virus scans (unsuccessfully) but
>> again I wouldn't call those "updates".
> Nor I. No, I'm only talking about your script. Does it bear any
> relation to the one posted in your blog? The first line (after
> the shebang) of the one in the blog is the same line that's under
> discussion here, and has curly quotes. I can't parse the second
> line's curly quotes, and the fourth line uses an n-dash for a
> hyphen *though the other hyphens are ok). The fifth line uses
> curly single-quotes. More curly quotes follow.
>
> I don't see any cause for our wasting time pondering on dash
> without your posting an MWE that unambiguously demonstrates a
> problem.
Yes, that's the script - copy-pasted from the working server then with 
the e-mail addresses changed (they are actually parameters to the 
working script, but why complicate things when explaining a basic 
script). As you noted, it has changed things - hopefully not to the 
point that people won't be able to make it work. I haven't found a way 
to stop Wordpress from doing the substitution but I note the raw text is 
still correct (once you remove the html).

[toc] | [prev] | [next] | [standalone]

#227273 — Re: weird behaviour of quotes in dash variable assignments

On Tue 22 Sep 2020 at 13:31:33 (-0400), Gary Dale wrote:
> On 2020-09-22 09:29, David Wright wrote:
> > On Mon 21 Sep 2020 at 20:50:29 (-0400), Gary Dale wrote:
> > > On 2020-09-21 10:30, David Wright wrote:

> > > > I think we should apply Hanlon's razor rather than saying the OP lied.
> > > > After all, "compare" means diff or cmp to us, whereas many might just
> > > > use their eyeballs. And we all know that authors are the worst people
> > > > to check their own work. Proof-reading is a special skill.
> > > > 
> > > > Even their fix is poorly described. Did they just type the quotes back
> > > > in with an editor, in which case there's no guarantee that the scripts
> > > > are identical between machines, or did they transfer a working script
> > > > to the failing machine? The best line is save until last: "I certainly
> > > > didn't update anything on either server...". Well, yes, that's
> > > > *precisely* what you did: you updated the script.
> >                                ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
> > > You are taking my quote out of context. I didn't change anything on
> > > the server to make the script start working. I updated the script to
> >                                                 ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
> > > see if it would work after trying Greg's test. There were no program
> > > or setting updates on the server, and certainly nothing that updated
> > > dash. This is Debian/Stable we're talking about, after all.
> > Sorry, I thought you wrote that on Sunday afternoon, "I fixed it by
> > removing the quotes on the one server but now the scripts are
> > different between the two servers, which isn't what I want."
> > Then on Sunday evening, you wrote "When I retried my script with the
> > quotes, it started working."
> > 
> > The general opinion is that the script was faulty, probably in the
> > quotes used. The narrative says that you removed the quotes, and
> > later put them back. It seems fair to suggest that the quotes you
> > put back were not the same ones that you removed. They were replaced
> > in the same location, but you didn't put the old (removed) quotes
> > into a little two-character file, so that you could put precisely
> > the same ones back into the script, did you?
> I thought about that but then there would be no way I could
> demonstrate it other than what I did - post the offending line via cut
> & paste, a method people have been arguing can change the quotes.
> > 
> > > Since it is a file server, there probably were changes to the files on
> > > its shares, but I'd hardly count that as an "update". Similarly, it
> > > was running cron jobs for backups and virus scans (unsuccessfully) but
> > > again I wouldn't call those "updates".
> > Nor I. No, I'm only talking about your script. Does it bear any
> > relation to the one posted in your blog? The first line (after
> > the shebang) of the one in the blog is the same line that's under
> > discussion here, and has curly quotes. I can't parse the second
> > line's curly quotes, and the fourth line uses an n-dash for a
> > hyphen *though the other hyphens are ok). The fifth line uses
> > curly single-quotes. More curly quotes follow.
> > 
> > I don't see any cause for our wasting time pondering on dash
> > without your posting an MWE that unambiguously demonstrates a
> > problem.
> Yes, that's the script - copy-pasted from the working server then with
> the e-mail addresses changed (they are actually parameters to the
> working script, but why complicate things when explaining a basic
> script). As you noted, it has changed things - hopefully not to the
> point that people won't be able to make it work. I haven't found a way
> to stop Wordpress from doing the substitution but I note the raw text
> is still correct (once you remove the html).

That I can believe. The substitutions appear to be systematic,
<non-space><quote> → 99-style, and <space><quote> → 66-style,
-- → n-dash, --- → m-dash; I think that covers it. And that might be
something you cannot change: I see it converts your apostrophes
in running text too.

But I don't see why you can't post emails with unadulterated
characters. You can obviously read and copy the working script
yourself, so you can at least paste it into a file on your
email computer, using   cat >file   if necessary¹, and then
InsertFile the file into your email composer. Your running text
has ASCII quotes, after all. That should avoid any problem like
https://lists.debian.org/debian-user/2020/09/msg00677.html
where your script fragment *still* has curly quotes but your
speech marks are ASCII.

I think it's reasonable, when you're reporting non-identical
behaviour from supposedly identical systems, to expect some
demonstration that the test cases and the reporting thereof
are, in fact, using identical scripts before eliminating
them from consideration.

¹ Run md5sum, as suggested earlier, on this file, the servers'
  scripts, and any cut-down versions, to demonstrate they're
  all the same. This avoids transferring files.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#227214 — Re: weird behaviour of quotes in dash variable assignments

On 2020-09-21 08:18, Greg Wooledge wrote:
> On Mon, Sep 21, 2020 at 07:55:45AM -0400, Cindy Sue Causey wrote:
>> '…' and "…" are known as neutral, vertical, straight, typewriter,
>> dumb, or ASCII quotation marks.
>>
>> ‘…’ and “…” are known as typographic, curly, curved, book, or smart
>> quotation marks.
> Yes.  This is one of the possible causes for the behavior the OP was
> reporting.  But if this is true, then it reveals that they were lying
> when they claimed that the scripts were the same on both servers.
>
>> They function differently somehow, too. I don't remember if that
>> difference in functioning was by design or just bad placement in a
>> file. Maybe it's about the above reference to ASCII. Discovering the
>> difference between them was another one of those ah-ha moments tripped
>> over via a terminal window.
> Remember, the computer can't actually *see* the characters the way
> that you do.  To the computer, every character is just a number, or
> a sequence of numbers.
>
> To bash, the character " (byte value 0x22) has a special meaning, and
> so does the character ' (byte value 0x27).  However, the characters
> “ (byte values 0xe2809c) and ” (byte values 0xe2809d) have no special
> meaning.  They're just some random data that the shell doesn't interpret.
>
> unicorn:~$ x="foo"; echo "$x"
> foo
> unicorn:~$ x='foo'; echo "$x"
> foo
> unicorn:~$ x=“foo”; echo "$x"
> “foo”
>
> To beat a dead horse some more, if *this* was the OP's problem, then they
> told multiple lies about it.  They did not paste the actual failing line
> from the failing script (probably retyped it instead), and they did not
> ACTUALLY COMPARE the two scripts to see whether they were different,
> instead simply ASSUMING that the two scripts were identical, even though
> they very clearly weren't.
>
> An actual troubleshooting would have done something like using md5sum
> on the script on each machine, and pasting the md5sum commands (including
> the full script pathname) and their output to the mailing list.  Openness.
>
> Or, hell, even "ls -l /full/pathname" would probably have revealed that
> the scripts were not the same SIZE.  That would also have shown immediately
> that the scripts were not "the same".
>
As an FYI, the scripts were the same on both servers because I had ssh 
sessions on both and copy/pasted the script from one to the other. (cat 
<script> on server 1, then use Konsole's copy and paste to select and 
paste it into nano on server 2).

[toc] | [prev] | [next] | [standalone]

#227215 — Re: weird behaviour of quotes in dash variable assignments

On Mon, Sep 21, 2020 at 12:34:20PM -0400, Gary Dale wrote:
> As an FYI, the scripts were the same on both servers because I had ssh
> sessions on both and copy/pasted the script from one to the other. (cat
> <script> on server 1, then use Konsole's copy and paste to select and paste
> it into nano on server 2).

Copy and paste doesn't always preserve the actual contents of a file.
What you get depends on several factors, including the behavior of the
terminal emulator that you're copying from.  Tabs may be converted to
spaces, and I have no idea what other changes may occur.

As a demonstration for myself, just now, I performed the following
experiment in both rxvt-unicode and xterm, on Debian 10:

1) Run the command:  printf 'a\tb\n'
2) Run the command:  hd
3) Highlight the line containing the output of the first command, and paste
   it into the terminal, to be read by hd.
4) Press Ctrl-D.

On rxvt-unicode, I get this output:

00000000  61 09 62 0a                                       |a.b.|
00000004

On xterm, I get this output:

00000000  61 20 20 20 20 20 20 20  62 0a                    |a       b.|
0000000a

If your original script contained non-breaking spaces, or curly quotes,
or literal tabs, or who knows what else, then there's a nonzero chance
it will be altered by the copy/paste.

This is why you need to *verify* that the two scripts are the same, not
just assume that pasting did what you thought it did.

[toc] | [prev] | [next] | [standalone]

#227216 — Re: weird behaviour of quotes in dash variable assignments

On 2020-09-21 12:43, Greg Wooledge wrote:
> On Mon, Sep 21, 2020 at 12:34:20PM -0400, Gary Dale wrote:
>> As an FYI, the scripts were the same on both servers because I had ssh
>> sessions on both and copy/pasted the script from one to the other. (cat
>> <script> on server 1, then use Konsole's copy and paste to select and paste
>> it into nano on server 2).
> Copy and paste doesn't always preserve the actual contents of a file.
> What you get depends on several factors, including the behavior of the
> terminal emulator that you're copying from.  Tabs may be converted to
> spaces, and I have no idea what other changes may occur.
>
> As a demonstration for myself, just now, I performed the following
> experiment in both rxvt-unicode and xterm, on Debian 10:
>
> 1) Run the command:  printf 'a\tb\n'
> 2) Run the command:  hd
> 3) Highlight the line containing the output of the first command, and paste
>     it into the terminal, to be read by hd.
> 4) Press Ctrl-D.
>
> On rxvt-unicode, I get this output:
>
> 00000000  61 09 62 0a                                       |a.b.|
> 00000004
>
> On xterm, I get this output:
>
> 00000000  61 20 20 20 20 20 20 20  62 0a                    |a       b.|
> 0000000a
>
> If your original script contained non-breaking spaces, or curly quotes,
> or literal tabs, or who knows what else, then there's a nonzero chance
> it will be altered by the copy/paste.
>
> This is why you need to *verify* that the two scripts are the same, not
> just assume that pasting did what you thought it did.
>
Did you try it with Konsole? I got

$ hd
a       b
00000000  61 20 20 20 20 20 20 20  62 0a |a       b.|
0000000a

Most shells (all that I am aware of) treat tabs and blanks as generic 
white space - not relevant to the execution of the code.

[toc] | [prev] | [next] | [standalone]

#227217 — Re: weird behaviour of quotes in dash variable assignments

On Mon, Sep 21, 2020 at 12:59:32PM -0400, Gary Dale wrote:
> Did you try it with Konsole? I got
> 
> $ hd
> a       b
> 00000000  61 20 20 20 20 20 20 20  62 0a |a       b.|
> 0000000a

In other words, konsole *did* alter the contents.

> Most shells (all that I am aware of) treat tabs and blanks as generic white
> space - not relevant to the execution of the code.

Between arguments, sure.  Tabs and spaces are equivalent in those places.
But inside a quoted string argument?  No, they're not equivalent.

Who knows what other conversions might have taken place?

You were trying to troubleshoot a script that wasn't doing what you
expected.  And yet you just hand-waved everything, rather than getting
in there and doing the work to actually *check* things.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web