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 2 of 2 — ← Prev page 1 [2]

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

On 2020-09-21 13:12, Greg Wooledge wrote:
> 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.
>
That's where you are making unwarranted assumptions. I tried the line 
outside of the script, hand entered rather than copied & pasted, and got 
the same result. There was something weird going on in the dash shell at 
the time. Just because I didn't report all the testing I'd done doesn't 
mean you should assume that I didn't do it.

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

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

On Mon 21 Sep 2020 at 12:43:52 (-0400), 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.
> 
> […]
> 
> 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.

Perhaps this paragraph illustrates the problems that can arise
with quotation marks, hyphens, etc:

#!/bin/sh
report=”/root/clamscan-report”
subject=$HOSTNAME” clamscan report: “

mv $report $report.prev
/usr/bin/clamscan –quiet -i -r -l $report /home
sed -i ‘/———– SCAN SUMMARY ———–/,$d’ $report
diff $report $report.prev > $report.diff

if [ -s $report.diff ] ; then
    subject=$subject”ALERT – NEW VIRUSES FOUND”
else
    subject=$subject”no new viruses”
fi
mail -r “<sender>” -s “$subject” <to e-mail> < $report.diff

Copied and pasted from firefox to emacs -nw, but checked
against the saved web page:

https://garydale.wordpress.com/

Cheers,
David.

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

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

On 2020-09-21 09:34, 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).

That process may have changed the file in invisible ways.  Use 
hexdump(1) to check for differences.  See below examples.


Use scp(1), rsync(1), sshfs(1), a networked version control system such 
as cvs(1), etc., to copy files accurately.


On 2020-09-21 09:59, Gary Dale wrote:
 > Most shells (all that I am aware of) treat tabs and blanks as generic
 > white space - not relevant to the execution of the code.

"I guess so".  (Obviously, I am not a dash(1) shell scripting expert.)


I have greater confidence in my ability to copy files accurately, and 
thereby eliminate one set of potential problems.  If the problem does 
turn out to be spaces and tabs in code, hopefully the script will 
misbehave consistently and I will figure it out.


David



2020-09-21 13:01:00 dpchrist@tinkywinky ~
$ cat /etc/debian_version ; uname -a ; dpkg-query --show xfce4 ; 
dpkg-query --show vim
9.13
Linux tinkywinky 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05) 
x86_64 GNU/Linux
xfce4	4.12.3
vim	2:8.0.0197-4+deb9u3


Test #1 -- copy and paste from cat(1) to vim(1)
===============================================

Terminal #1
-----------

2020-09-21 12:13:03 dpchrist@tinkywinky ~
$ vi foo

2020-09-21 12:13:54 dpchrist@tinkywinky ~
$ cat foo
I am foo!
	leading tab
Foo on you!
trailing tab	

2020-09-21 12:13:57 dpchrist@tinkywinky ~
$ hexdump foo
00000000  49 20 61 6d 20 66 6f 6f  21 0a 09 6c 65 61 64 69  |I am 
foo!..leadi|
00000010  6e 67 20 74 61 62 0a 46  6f 6f 20 6f 6e 20 79 6f  |ng tab.Foo 
on yo|
00000020  75 21 0a 74 72 61 69 6c  69 6e 67 20 74 61 62 09  |u!.trailing 
tab.|
00000030  0a                                                |.|
00000031

<mouse drag and highlight cat(1) output>


Terminal #2
-----------

2020-09-21 12:01:15 dpchrist@tinkywinky ~
$ vi bar

<mouse middle click and paste text into edit buffer, save, exit>

2020-09-21 12:15:07 dpchrist@tinkywinky ~
$ cat bar
I am foo!
	leading tab
Foo on you!
trailing tab	


2020-09-21 12:16:06 dpchrist@tinkywinky ~
$ hexdump bar
00000000  49 20 61 6d 20 66 6f 6f  21 0a 09 6c 65 61 64 69  |I am 
foo!..leadi|
00000010  6e 67 20 74 61 62 0a 46  6f 6f 20 6f 6e 20 79 6f  |ng tab.Foo 
on yo|
00000020  75 21 0a 74 72 61 69 6c  69 6e 67 20 74 61 62 09  |u!.trailing 
tab.|
00000030  0a 0a                                             |..|
00000032


Result: there is an extra newline at the end of 'bar'.


Test #2 -- copy and paste from less(1) to vim(1)
================================================

Terminal #3
-----------

2020-09-21 12:25:49 dpchrist@tinkywinky ~
$ less foo

<mouse drag and highlight text within less(1) display>


Terminal #4
-----------

2020-09-21 12:26:25 dpchrist@tinkywinky ~
$ vi baz

<mouse middle click and paste text into edit buffer, save, exit>

2020-09-21 13:06:14 dpchrist@tinkywinky ~
$ cat baz
I am foo!
         leading tab
Foo on you!
trailing tab

2020-09-21 13:06:16 dpchrist@tinkywinky ~
$ hexdump baz
00000000  49 20 61 6d 20 66 6f 6f  21 0a 20 20 20 20 20 20  |I am foo!. 
     |
00000010  20 20 6c 65 61 64 69 6e  67 20 74 61 62 0a 46 6f  |  leading 
tab.Fo|
00000020  6f 20 6f 6e 20 79 6f 75  21 0a 74 72 61 69 6c 69  |o on 
you!.traili|
00000030  6e 67 20 74 61 62 20 20  20 20 0a 0a              |ng tab    ..|
0000003c


Result: Both tabs have been replaced with spaces and there is an extra 
newline at the end of 'baz'.

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

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

On 2020-09-21 16:18, David Christensen wrote:
> On 2020-09-21 09:34, 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).
>
> That process may have changed the file in invisible ways.  Use 
> hexdump(1) to check for differences.  See below examples.
>
>
> Use scp(1), rsync(1), sshfs(1), a networked version control system 
> such as cvs(1), etc., to copy files accurately.
>
>
> On 2020-09-21 09:59, Gary Dale wrote:
> > Most shells (all that I am aware of) treat tabs and blanks as generic
> > white space - not relevant to the execution of the code.
>
> "I guess so".  (Obviously, I am not a dash(1) shell scripting expert.)
>
>
> I have greater confidence in my ability to copy files accurately, and 
> thereby eliminate one set of potential problems.  If the problem does 
> turn out to be spaces and tabs in code, hopefully the script will 
> misbehave consistently and I will figure it out.
>
>
> David
>
>
>
> 2020-09-21 13:01:00 dpchrist@tinkywinky ~
> $ cat /etc/debian_version ; uname -a ; dpkg-query --show xfce4 ; 
> dpkg-query --show vim
> 9.13
> Linux tinkywinky 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05) 
> x86_64 GNU/Linux
> xfce4    4.12.3
> vim    2:8.0.0197-4+deb9u3
>
>
> Test #1 -- copy and paste from cat(1) to vim(1)
> ===============================================
>
> Terminal #1
> -----------
>
> 2020-09-21 12:13:03 dpchrist@tinkywinky ~
> $ vi foo
>
> 2020-09-21 12:13:54 dpchrist@tinkywinky ~
> $ cat foo
> I am foo!
>     leading tab
> Foo on you!
> trailing tab
>
> 2020-09-21 12:13:57 dpchrist@tinkywinky ~
> $ hexdump foo
> 00000000  49 20 61 6d 20 66 6f 6f  21 0a 09 6c 65 61 64 69  |I am 
> foo!..leadi|
> 00000010  6e 67 20 74 61 62 0a 46  6f 6f 20 6f 6e 20 79 6f  |ng 
> tab.Foo on yo|
> 00000020  75 21 0a 74 72 61 69 6c  69 6e 67 20 74 61 62 09 
> |u!.trailing tab.|
> 00000030  0a                                                |.|
> 00000031
>
> <mouse drag and highlight cat(1) output>
>
>
> Terminal #2
> -----------
>
> 2020-09-21 12:01:15 dpchrist@tinkywinky ~
> $ vi bar
>
> <mouse middle click and paste text into edit buffer, save, exit>
>
> 2020-09-21 12:15:07 dpchrist@tinkywinky ~
> $ cat bar
> I am foo!
>     leading tab
> Foo on you!
> trailing tab
>
>
> 2020-09-21 12:16:06 dpchrist@tinkywinky ~
> $ hexdump bar
> 00000000  49 20 61 6d 20 66 6f 6f  21 0a 09 6c 65 61 64 69  |I am 
> foo!..leadi|
> 00000010  6e 67 20 74 61 62 0a 46  6f 6f 20 6f 6e 20 79 6f  |ng 
> tab.Foo on yo|
> 00000020  75 21 0a 74 72 61 69 6c  69 6e 67 20 74 61 62 09 
> |u!.trailing tab.|
> 00000030  0a 0a                                             |..|
> 00000032
>
>
> Result: there is an extra newline at the end of 'bar'.
>
>
> Test #2 -- copy and paste from less(1) to vim(1)
> ================================================
>
> Terminal #3
> -----------
>
> 2020-09-21 12:25:49 dpchrist@tinkywinky ~
> $ less foo
>
> <mouse drag and highlight text within less(1) display>
>
>
> Terminal #4
> -----------
>
> 2020-09-21 12:26:25 dpchrist@tinkywinky ~
> $ vi baz
>
> <mouse middle click and paste text into edit buffer, save, exit>
>
> 2020-09-21 13:06:14 dpchrist@tinkywinky ~
> $ cat baz
> I am foo!
>         leading tab
> Foo on you!
> trailing tab
>
> 2020-09-21 13:06:16 dpchrist@tinkywinky ~
> $ hexdump baz
> 00000000  49 20 61 6d 20 66 6f 6f  21 0a 20 20 20 20 20 20  |I am 
> foo!.     |
> 00000010  20 20 6c 65 61 64 69 6e  67 20 74 61 62 0a 46 6f  | leading 
> tab.Fo|
> 00000020  6f 20 6f 6e 20 79 6f 75  21 0a 74 72 61 69 6c 69  |o on 
> you!.traili|
> 00000030  6e 67 20 74 61 62 20 20  20 20 0a 0a              |ng tab    
> ..|
> 0000003c
>
>
> Result: Both tabs have been replaced with spaces and there is an extra 
> newline at the end of 'baz'.

The two servers are for different customers. I would not want to create 
a tunnel between them. Instead I have my normal ssh tunnels to each 
server from my workstation. However the script is only readable by root 
while my tunnels are for my non-root account. While I could copy the 
file to my non-root account (while root), chown it, copy it to my 
workstation then to the other server, where I'd move it to /root, that's 
a lot more work than cat, copy, paste, save.

Again, the method I used should not have created any changes in the 
script that would affect its operation. And to date I've seen no 
indication that it did. I still don't know why the script was leaving 
the quotes in nor why it started working.

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

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

On 2020-09-21 18:04, Gary Dale wrote:

> The two servers are for different customers. I would not want to create 
> a tunnel between them. Instead I have my normal ssh tunnels to each 
> server from my workstation. However the script is only readable by root 
> while my tunnels are for my non-root account. While I could copy the 
> file to my non-root account (while root), chown it, copy it to my 
> workstation then to the other server, where I'd move it to /root, that's 
> a lot more work than cat, copy, paste, save.
> 
> Again, the method I used should not have created any changes in the 
> script that would affect its operation. And to date I've seen no 
> indication that it did. I still don't know why the script was leaving 
> the quotes in nor why it started working.

You might want to consider ssh-agent and SSH agent forwarding.  These 
allow you to access your version control server over SSH from remote 
hosts by using your workstation credentials; no credentials required on 
the remote host:

 
https://dev.to/levivm/how-to-use-ssh-and-ssh-agent-forwarding-more-secure-ssh-2c32


David

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

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

On 2020-09-22 00:25, David Christensen wrote:
> On 2020-09-21 18:04, Gary Dale wrote:
>
>> The two servers are for different customers. I would not want to 
>> create a tunnel between them. Instead I have my normal ssh tunnels to 
>> each server from my workstation. However the script is only readable 
>> by root while my tunnels are for my non-root account. While I could 
>> copy the file to my non-root account (while root), chown it, copy it 
>> to my workstation then to the other server, where I'd move it to 
>> /root, that's a lot more work than cat, copy, paste, save.
>>
>> Again, the method I used should not have created any changes in the 
>> script that would affect its operation. And to date I've seen no 
>> indication that it did. I still don't know why the script was leaving 
>> the quotes in nor why it started working.
>
> You might want to consider ssh-agent and SSH agent forwarding. These 
> allow you to access your version control server over SSH from remote 
> hosts by using your workstation credentials; no credentials required 
> on the remote host:
>
>
> https://dev.to/levivm/how-to-use-ssh-and-ssh-agent-forwarding-more-secure-ssh-2c32 
>
>
>
> David
>
I'm not sure that does anything for me. I would need to create a "root" 
key to get access to the file, which is something I refuse to do.

Right now the ssh tunnel requires a key on the remote server and there 
are no root keys so even if someone gains access, they still don't have 
root access.

There are other tools that work better for pushing things to multiple 
servers but all of these tools assume you are doing it often enough or 
to enough machines to make it worthwhile. That's not my situation.

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

#227263 — SSH agent forwarding (was: weird behaviour of quotes in dash variable assignments)

On 2020-09-22 13:05, Gary Dale wrote:
> On 2020-09-22 00:25, David Christensen wrote:
>> On 2020-09-21 18:04, Gary Dale wrote:
>>
>>> The two servers are for different customers. I would not want to 
>>> create a tunnel between them. Instead I have my normal ssh tunnels to 
>>> each server from my workstation. However the script is only readable 
>>> by root while my tunnels are for my non-root account. While I could 
>>> copy the file to my non-root account (while root), chown it, copy it 
>>> to my workstation then to the other server, where I'd move it to 
>>> /root, that's a lot more work than cat, copy, paste, save.
>>>
>>> Again, the method I used should not have created any changes in the 
>>> script that would affect its operation. And to date I've seen no 
>>> indication that it did. I still don't know why the script was leaving 
>>> the quotes in nor why it started working.
>>
>> You might want to consider ssh-agent and SSH agent forwarding. These 
>> allow you to access your version control server over SSH from remote 
>> hosts by using your workstation credentials; no credentials required 
>> on the remote host:
>>
>>
>> https://dev.to/levivm/how-to-use-ssh-and-ssh-agent-forwarding-more-secure-ssh-2c32 
>>
>>
>>
>> David
>>
> I'm not sure that does anything for me. I would need to create a "root" 
> key to get access to the file, which is something I refuse to do.

This book is relevant:

     https://mwl.io/nonfiction/tools#ssh


Here is my workstation.  I will demonstrate SSH agent forwarding using 
it both as the workstation and as the server:

2020-09-22 14:57:40 root@tinkywinky ~
# cat /etc/debian_version ; uname -a
9.13
Linux tinkywinky 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05) 
x86_64 GNU/Linux


The workstation and the server must have at least one SSH host key pair. 
  The Debian installer creates three:

2020-09-22 14:49:56 dpchrist@tinkywinky ~
$ ls -1 /etc/ssh/ssh_host*key*
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ecdsa_key.pub
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_ed25519_key.pub
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key.pub


The workstation user account must have at least one SSH user key pair:

2020-09-22 14:51:21 dpchrist@tinkywinky ~
$ ls -1 .ssh/id_rsa*
.ssh/id_rsa
.ssh/id_rsa.pub


No root account key pair is required on the server.


The server root account authorized_keys file must contain the 
workstation user account public key(s).  Append the contents of 
~/.ssh/id_rsa.pub from the workstation to /root/.ssh/authorized_keys on 
the server.


Agent forwarding must be enabled on the workstation:

2020-09-22 14:55:20 dpchrist@tinkywinky ~
$ egrep ^ForwardAgent /etc/ssh/ssh_config
ForwardAgent yes


Root public key authentication must be enabled on the server (it is 
enabled by default on my Debian machines):

2020-09-22 14:56:32 dpchrist@tinkywinky ~
$ egrep PermitRootLogin /etc/ssh/sshd_config | head -n 1
PermitRootLogin prohibit-password


Restart sshd on the server, if required:

2020-09-22 14:57:35 root@tinkywinky ~
# service sshd restart


Start a terminal on the workstation.  Start ssh-agent(1) using your 
shell of choice (with any required options or arguments):

2020-09-22 15:01:31 dpchrist@tinkywinky ~
$ ssh-agent bash -l


Add your user account key pair to the SSH agent:

2020-09-22 15:01:34 dpchrist@tinkywinky ~
$ ssh-add
Enter passphrase for /home/dpchrist/.ssh/id_rsa:
Identity added: /home/dpchrist/.ssh/id_rsa (/home/dpchrist/.ssh/id_rsa)


Log in as root on the server via public key authentication (no 
passphrase required):

2020-09-22 15:02:09 dpchrist@tinkywinky ~
$ ssh root@localhost
Linux tinkywinky 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05) x86_64
Last login: Tue Sep 22 14:57:35 2020 from ::1

2020-09-22 15:02:35 root@tinkywinky ~
#


Now I can use my workstation user account credentials on the remote 
machine just like I would use them locally (via agent forwarding; no 
passphrase required):

2020-09-22 15:02:35 root@tinkywinky ~
# cvs diff


Optionally, you can disable password authentication on the server and 
restart sshd.  The only way to log in will be via the console or via SSH 
public key authentication:

2020-09-22 15:04:40 root@tinkywinky ~
# grep Password /etc/ssh/sshd_config
PasswordAuthentication no

2020-09-22 15:22:05 root@tinkywinky ~
# service sshd restart


> Right now the ssh tunnel requires a key on the remote server 

I don't use SSH tunnels (yet).  The SSH agent forwarding technique I 
demonstrated above does not require any user or root keys on the server.


> and there 
> are no root keys so even if someone gains access, they still don't have 
> root access.

If someone gains access to what?


> There are other tools that work better for pushing things to multiple 
> servers but all of these tools assume you are doing it often enough or 
> to enough machines to make it worthwhile. That's not my situation.

Ansible, Puppet, etc., seem like overkill for my needs.  I have not used 
them.


I use ssh-agent(1), scp(1), and ssh(1) interactively, and I wrote shell 
scripts, Perl scripts, and Makefiles to automate repetitive tasks.


CVS allows me to develop scripts and Makefiles on any machine, check 
them in, and check out exact copies on every other machine.  If I edit 
one file on two machines, CVS knows how to solve the three-way merge 
problem (for text files, not for binary files).  CVS is very useful, 
saves time, and eliminates the chaos of sneakernet, cut-and-paste, etc.. 
  Any other good networked version control system should do the same.


David

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

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

On Sun, Sep 20, 2020 at 09:18:33PM -0400, Gary Dale wrote:
> > > > The line causing the problem reads: report="/root/clamscan-report"

There is nothing wrong with that alleged line.

There is an incredible lack of openness and forthrightness in this
thread.  What are you hiding?  Why are you hiding it?

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

False.  Either type of quotes is perfectly fine in this case.

The fact that you make this claim tells me one of the following two
things is true:

 * You have no idea what you're doing, and you are GUESSING that
   changing the quotes would cause an issue, but you did not actually
   try it.

 * The whole discussion is founded on falsehoods.  There's something
   you're not telling us.  The "line" in question is falsified, or it's
   part of some larger context which is being hidden, and this context
   is vitally important to understanding the problem.

I'm leaning toward the latter.

What you should do is produce the smallest possible script that still
exhibits the problem, and post that script, plus its output.  Obviously
you'd add something like  echo "$report"  to the script.  Even better
would be  printf '%s\n' "$report"  .  Better still would be
printf %s "$report" | hd  .  Or you could just add set -x to the script.

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

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

On 2020-09-21 07:51, Greg Wooledge wrote:
> On Sun, Sep 20, 2020 at 09:18:33PM -0400, Gary Dale wrote:
>>>>> The line causing the problem reads: report="/root/clamscan-report"
> There is nothing wrong with that alleged line.
>
> There is an incredible lack of openness and forthrightness in this
> thread.  What are you hiding?  Why are you hiding it?

Nothing. Just not sharing extraneous details.


>>> Have you tried single quotes?
>> Wouldn't want to. Single quotes alter the behaviour.
> False.  Either type of quotes is perfectly fine in this case.

The key words being "in this case". As I explained elsewhere in this 
thread, I avoid using single-quotes except when I need them. Otherwise 
anyone reading the script wouldn't know if the single quotes were needed 
or not. This is fairly standard practise, as far as I've seen, when 
writing scripts.


>
> The fact that you make this claim tells me one of the following two
> things is true:
>
>   * You have no idea what you're doing, and you are GUESSING that
>     changing the quotes would cause an issue, but you did not actually
>     try it.
>
>   * The whole discussion is founded on falsehoods.  There's something
>     you're not telling us.  The "line" in question is falsified, or it's
>     part of some larger context which is being hidden, and this context
>     is vitally important to understanding the problem.
>
> I'm leaning toward the latter.
>
> What you should do is produce the smallest possible script that still
> exhibits the problem, and post that script, plus its output.  Obviously
> you'd add something like  echo "$report"  to the script.  Even better
> would be  printf '%s\n' "$report"  .  Better still would be
> printf %s "$report" | hd  .  Or you could just add set -x to the script.
>
The smallest possible script was what I posted - the single line copied 
and pasted from the script it was running in. It was the first line 
after the shebang.

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

#227184

On 2020-09-20 18: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?

I'm in the habit of always quoting string constants in scripts. It's 
clearer and avoids potential problems with future edits...


>
>> 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.

It's the same version of bash, as you would expect since both servers 
are running the same up-to-date version of Debian/Stable.

The echo command is reporting things accurately. I uncovered the problem 
by running the script manually and seeing the messages coming up showing 
that it was looking for a file enclosed in quotes. The other server was 
running the script without errors.

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

#227201

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

On Sun, Sep 20, 2020 at 05:27:49PM -0400, 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. More
> importantly, I don't understand why it refuses to remove the quotes.
> 
> Where does this behaviour (keeping the quotes) get set?

What does the builtin "shopt" say? Especially the value of `compat42'
is involved in quote removal.

Cheers
 - t

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

#227222

On 2020-09-21 00:52, tomas@tuxteam.de wrote:
> On Sun, Sep 20, 2020 at 05:27:49PM -0400, Gary Dale wrote:

>> Where does this behaviour (keeping the quotes) get set?
> 
> What does the builtin "shopt" say? Especially the value of `compat42'
> is involved in quote removal.

Joy! Joy! Happy! Happy!  Another whole dimension for potential problems!


2020-09-21 12:47:06 dpchrist@tinkywinky ~
$ cat /etc/debian_version ; uname -a ; dpkg-query --show dash
9.13
Linux tinkywinky 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05) 
x86_64 GNU/Linux
dash	0.5.8-2.4

2020-09-21 12:48:31 dpchrist@tinkywinky ~
$ shopt
autocd         	off
cdable_vars    	off
cdspell        	off
checkhash      	off
checkjobs      	off
checkwinsize   	on
cmdhist        	on
compat31       	off
compat32       	off
compat40       	off
compat41       	off
compat42       	off
compat43       	off
complete_fullquote	on
direxpand      	off
dirspell       	off
dotglob        	off
execfail       	off
expand_aliases 	on
extdebug       	off
extglob        	on
extquote       	on
failglob       	off
force_fignore  	on
globasciiranges	off
globstar       	off
gnu_errfmt     	off
histappend     	off
histreedit     	off
histverify     	off
hostcomplete   	off
huponexit      	off
inherit_errexit	off
interactive_comments	on
lastpipe       	off
lithist        	off
login_shell    	on
mailwarn       	off
no_empty_cmd_completion	off
nocaseglob     	off
nocasematch    	off
nullglob       	off
progcomp       	on
promptvars     	on
restricted_shell	off
shift_verbose  	off
sourcepath     	on
xpg_echo       	off


RTFM dash(1) I don't see any 'compat' keywords... (?)


STFW https://html.duckduckgo.com/html?q=dash%20compat42 I don't see 
'compat' anywhere on the first page of hits... (?)


Where are the above settings documented?


David

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

#227224

On Mon, Sep 21, 2020 at 01:19:22PM -0700, David Christensen wrote:
> On 2020-09-21 00:52, tomas@tuxteam.de wrote:
> > What does the builtin "shopt" say? Especially the value of `compat42'
> > is involved in quote removal.
> 
> Joy! Joy! Happy! Happy!  Another whole dimension for potential problems!

There is great confusion here, because the OP was so vague and misleading
about *everything*.  Including which shell was being used.

"compat42" and "shopt" are bashisms.  They are not present nor relevant
in dash.

> RTFM dash(1) I don't see any 'compat' keywords... (?)

Correct.

> STFW https://html.duckduckgo.com/html?q=dash%20compat42 I don't see 'compat'
> anywhere on the first page of hits... (?)
> 
> Where are the above settings documented?

In bash(1).  They are bash settings.

To the best of my knowledge, there is no bash shopt or compat* setting
that will change the behavior of quotes in such a profound way as to
cause the problem that the OP imagined he had.

At this point, I'm still convinced that it was a curly-quote issue.  Of
course, we'll never know for sure, because the OP is incapable of presenting
simple facts like "here is the script which fails" and "here is its output".

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

#227225

On 2020-09-21 16:28, Greg Wooledge wrote:
> On Mon, Sep 21, 2020 at 01:19:22PM -0700, David Christensen wrote:
>> On 2020-09-21 00:52, tomas@tuxteam.de wrote:
>>> What does the builtin "shopt" say? Especially the value of `compat42'
>>> is involved in quote removal.
>> Joy! Joy! Happy! Happy!  Another whole dimension for potential problems!
> There is great confusion here, because the OP was so vague and misleading
> about *everything*.  Including which shell was being used.
>
> "compat42" and "shopt" are bashisms.  They are not present nor relevant
> in dash.
>
>> RTFM dash(1) I don't see any 'compat' keywords... (?)
> Correct.
>
>> STFW https://html.duckduckgo.com/html?q=dash%20compat42 I don't see 'compat'
>> anywhere on the first page of hits... (?)
>>
>> Where are the above settings documented?
> In bash(1).  They are bash settings.
>
> To the best of my knowledge, there is no bash shopt or compat* setting
> that will change the behavior of quotes in such a profound way as to
> cause the problem that the OP imagined he had.
>
> At this point, I'm still convinced that it was a curly-quote issue.  Of
> course, we'll never know for sure, because the OP is incapable of presenting
> simple facts like "here is the script which fails" and "here is its output".
>
I presented the line that failed, copied and pasted from the Konsole 
session. What more do you want, other than to complain?

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

#227238

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

On Lu, 21 sep 20, 17:22:26, Gary Dale wrote:
> 
> I presented the line that failed, copied and pasted from the Konsole
> session. What more do you want, other than to complain?

In such cases it is best to attach[1] the smallest complete[2] script 
demonstrating the behaviour.

Based on the information provided so far it is highly likely the issue 
was caused by some detail you omitted because you decided it is not 
relevant.

[1] as demonstrated, copy-pasting can alter content
[2] as discussed, the shebang line can make a big difference

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#227256

On 2020-09-22 01:48, Andrei POPESCU wrote:
> On Lu, 21 sep 20, 17:22:26, Gary Dale wrote:
>> I presented the line that failed, copied and pasted from the Konsole
>> session. What more do you want, other than to complain?
> In such cases it is best to attach[1] the smallest complete[2] script
> demonstrating the behaviour.
>
> Based on the information provided so far it is highly likely the issue
> was caused by some detail you omitted because you decided it is not
> relevant.
>
> [1] as demonstrated, copy-pasting can alter content
> [2] as discussed, the shebang line can make a big difference
>
> Kind regards,
> Andrei

Your first point makes it impossible for me to present anything because 
this list doesn't (AFAIK) allow attachments. I can only present a 
copy-pasted example.

Your second point would assume that I'm using a non-standard shebang. I 
use #!/bin/sh unless I need something that is only available in bash 
(can't recall a case of that). Moreover, the consensus seems to be that 
if there was an error on the shebang line, the default shell would be used.

The smallest complete script then is

report=”/root/clamscan-report”
echo $report

but as I explained, that works on one server but not the other. Hence my 
question wasn't "what's wrong with this line" but rather "how do I 
change the behaviour". I'm not expecting anyone else to be able to 
reproduce the problem because I can't even do it except on the one server.

And to do that, I didn't even need the shebang line. I could enter the 
line at the command prompt then echo it and see the same result. Since 
it wasn't the shebang line, and didn't even require being in a script, 
why should I have included the shebang line?

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

#227261

On Tue, Sep 22, 2020 at 04:37:40PM -0400, Gary Dale wrote:
> The smallest complete script then is
> 
> report=”/root/clamscan-report”
> echo $report

There are three errors in this script.

1) There is no shebang line.
2) You've got curly quotes instead of ASCII double-quotes.
3) You used a variable expansion without enclosing it in double quotes,
   in a context where that matters.

If you literally can't see the difference between ”/root/clamscan-report”
and "/root/clamscan-report" (the former is what you have, and the latter
is what it *should* be), then you need to start working with a different
font.

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

#227268

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

On Ma, 22 sep 20, 16:37:40, Gary Dale wrote:
> 
> Your first point makes it impossible for me to present anything because this
> list doesn't (AFAIK) allow attachments.

This is a myth, I just attached a small script to this message.

The list apparently does indeed filter some attachments most likely 
based on size, possibly also type.

https://www.debian.org/MailingLists/#codeofconduct

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web