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 *
Reply to: