I have a shell script like the one depicted below as excerpt to invoke
simple ftp-transfers; the script invokes expect, and expect spawns ftp.
That script has issues with (today common) pathological file names.

How would the correct quoting be done to pass the file with the below
depicted filename through all these nested tools?

server=...
file='A (pathological) file name w/ blanks, parenthesis, etc.pdf'
....
expect <<EOT
spawn ftp -i "${server}"
....
expect "ftp> "
send "put ${file}\r"
....
EOT

Janis

On 28/01/2022 20:29, Janis Papanagnou wrote:
> I have a shell script like the one depicted below as excerpt to invoke
> simple ftp-transfers; the script invokes expect, and expect spawns ftp.
> That script has issues with (today common) pathological file names.
>
> How would the correct quoting be done to pass the file with the below
> depicted filename through all these nested tools?
>
>
> server=...
> file='A (pathological) file name w/ blanks, parenthesis, etc.pdf'
> ...
> expect <<EOT
> spawn ftp -i "${server}"
> ...
> expect "ftp> "
> send "put ${file}\r"
> ...
> EOT
>
>
> Janis
>

$file contains an illegal character (/) perhaps?

Why are you using expect?

ftp -niv $HOST <<EOT
$USER
$PWD
put $FILE
quit

seems to work.

--
Chris Elvidge
England

On 28/01/2022 22:39, Chris Elvidge wrote:
> On 28/01/2022 20:29, Janis Papanagnou wrote:
>> I have a shell script like the one depicted below as excerpt to invoke
>> simple ftp-transfers; the script invokes expect, and expect spawns ftp.
>> That script has issues with (today common) pathological file names.
>>
>> How would the correct quoting be done to pass the file with the below
>> depicted filename through all these nested tools?
>>
>>
>> server=...
>> file='A (pathological) file name w/ blanks, parenthesis, etc.pdf'
>> ...
>> expect <<EOT
>> spawn ftp -i "${server}"
>> ...
>> expect "ftp> "
>> send "put ${file}\r"
>> ...
>> EOT
>>
>>
>> Janis
>>
>
> $file contains an illegal character (/) perhaps?
>
> Why are you using expect?
>
> ftp -niv $HOST <<EOT
> $USER
> $PWD
> put $FILE
> quit
>
> seems to work.
>
Sorry forgot the EOT after quit.

--
Chris Elvidge
England

On 28/01/2022 20:29, Janis Papanagnou wrote:
> I have a shell script like the one depicted below as excerpt to invoke
> simple ftp-transfers; the script invokes expect, and expect spawns ftp.
> That script has issues with (today common) pathological file names.
>
> How would the correct quoting be done to pass the file with the below
> depicted filename through all these nested tools?
>
>
> server=...
> file='A (pathological) file name w/ blanks, parenthesis, etc.pdf'
> ...
> expect <<EOT
> spawn ftp -i "${server}"
> ...
> expect "ftp> "
> send "put ${file}\r"
> ...
> EOT
>
>
> Janis
>

Sorry, please disregard suggestion (except / in filename)

--
Chris Elvidge
England

On 28.01.2022 23:39, Chris Elvidge wrote:
> On 28/01/2022 20:29, Janis Papanagnou wrote:
>> I have a shell script like the one depicted below as excerpt to invoke
>> simple ftp-transfers; the script invokes expect, and expect spawns ftp.
>> That script has issues with (today common) pathological file names.
>>
>> How would the correct quoting be done to pass the file with the below
>> depicted filename through all these nested tools?
>>
>>
>> server=...
>> file='A (pathological) file name w/ blanks, parenthesis, etc.pdf'
>> ...
>> expect <<EOT
>> spawn ftp -i "${server}"
>> ...
>> expect "ftp> "
>> send "put ${file}\r"
>> ...
>> EOT
>>
>>
>> Janis
>>
>
> $file contains an illegal character (/) perhaps?

My fault; for posting purposes I made up a long file name and wanted
to abbreviate "with" with "w/", missing that this would change the
filename semantics. The actual filenames have blanks and parenthesis,
but no '/', '\', '\\' or other Unix/DOS directory separators.

>
> Why are you using expect?

When I wrote it ftp seemed to only support an interactive mode, so
I had to implement the question/answer protocol; the quasi-standard
tool for such tasks was expect.

>
> ftp -niv $HOST <<EOT
> $USER
> $PWD
> put $FILE
> quit
>
> seems to work.

I haven't tried it but I saw your other post "Sorry, please disregard
suggestion", and suppose you meant this one actually doesn't work?

Nevermind, I inspected per "apropos ftp" available programs and found
ncftpget and ncftpput. Yet I haven't tried them but they might serve
the tasks I have. Only thing I don't see in the man page is that there
seems to be no equivalent to mput/mget for the transfer of many files
available. (I'll have to see.) Avoiding the multiple authentications
with its delay in case of multiple file transfers would be desirable.

Besides this (potential) alternative I'd nonetheless be curious about
insights with regard of my original question; correct quoting through
several levels of these tools (in case I'll need it at times, or have
to resort to that approach).

Thanks.

Janis

In article <st1jn9$poc$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
>I have a shell script like the one depicted below as excerpt to invoke
>simple ftp-transfers; the script invokes expect, and expect spawns ftp.
>That script has issues with (today common) pathological file names.
>
>How would the correct quoting be done to pass the file with the below
>depicted filename through all these nested tools?
>
>
>server=...
>file='A (pathological) file name w/ blanks, parenthesis, etc.pdf'
>...
>expect <<EOT
>spawn ftp -i "${server}"
>...
>expect "ftp> "
>send "put ${file}\r"
>...
>EOT

There are basically 3 ways to "script" FTP transfers:

1) Directly. By this, I mean by supplying the actual FTP commands on stdin
and/or writing them to a file, then invoking FTP with some silly options to
get it to run in script mode. Most of the answers so far on this thread
have been in this category. I find this method hinky and try to avoid it
if at all possible.

2) Using Expect. This is the method I'm most comfortable with, and I
encourage you to stay with it. I would do it more like this, though:

#!/usr/bin/expect --
spawn ftp [lindex $argv 0]
....
expect "ftp> "
send "put [lindex $argv 1]\r"
....

Then I would call that script passing the server and the filename as
command line args. Note that in all my years of Expect scripting, I never
figured out a way to access the command line args (In Expect/TCL-speak,
$argv) from a command line (-c 'Expect Script Here') Expect program. It
only seems to work when the script is in a file. I am open to suggestions
about how to do that.

Note, BTW, that I *think* what you did originally would/should work if you
had used "-c" to pass the Expect script on the command line, rather than
feeding the script in via stdin.

3) Using some other command line tool that is designed for automating FTP
transfers. I've used ncftpget/ncftpput in the past; there are more
current versions of the general concept now, like "curl" and "iftp" and so
on. These all seem to work well, and I've nothing bad to say about them.

Finally, note that the oft-given-advice at this point is to not use FTP
since it is "insecure". The kewl people nowadays all use ssh/scp or some
variant thereof. Any particular reason you aren't doing that too? Any
reason you don't want all your friends to think you're kewl?

--
Faced with the choice between changing one's mind and proving that there is
no need to do so, almost everyone gets busy on the proof.

- John Kenneth Galbraith -

On Sa 29 Jan 2022 at 12:48, gazelle@shell.xmission.com (Kenny McCormack) wrote:

> 3) Using some other command line tool that is designed for automating FTP
> transfers. I've used ncftpget/ncftpput in the past; there are more
> current versions of the general concept now, like "curl" and "iftp" and so
> on. These all seem to work well, and I've nothing bad to say about them.

There is also lftp which works quite well with scripts.

'Andreas

On 1/28/2022 2:29 PM, Janis Papanagnou wrote:
> I have a shell script like the one depicted below as excerpt to invoke
> simple ftp-transfers; the script invokes expect, and expect spawns ftp.
> That script has issues with (today common) pathological file names.
>
> How would the correct quoting be done to pass the file with the below
> depicted filename through all these nested tools?
>
>
> server=...
> file='A (pathological) file name w/ blanks, parenthesis, etc.pdf'

Does updating it with printf '%q` get you to where you need to be:

$ file='A (pathological) file name w/ blanks, parenthesis, etc.pdf'
$ printf -v file '%q' "$file"
$ echo "$file"
A\ \(pathological\)\ file\ name\ w/\ blanks\,\ parenthesis\,\ etc.pdf

Ed.

> ...
> expect <<EOT
> spawn ftp -i "${server}"
> ...
> expect "ftp> "
> send "put ${file}\r"
> ...
> EOT
>
>
> Janis

In article <87ee4qit7q.fsf@eder.anydns.info>,
Andreas Eder <a_eder_muc@web.de> wrote:
>On Sa 29 Jan 2022 at 12:48, gazelle@shell.xmission.com (Kenny McCormack) wrote:
>
>> 3) Using some other command line tool that is designed for automating FTP
>> transfers. I've used ncftpget/ncftpput in the past; there are more
>> current versions of the general concept now, like "curl" and "iftp" and so
>> on. These all seem to work well, and I've nothing bad to say about them.
>
>There is also lftp which works quite well with scripts.

I think I meant to say 'lftp' when I said 'iftp'.

--
"I think I understand delicate, but why do I have to wash my hands, and
be standing in cold water when doing it?"

Kaz Kylheku <kaz@kylheku.com> in comp.lang.c

Thanks for your suggestions. At the moment just a quick response to this
question...

On 29.01.2022 13:48, Kenny McCormack wrote:
>
> Finally, note that the oft-given-advice at this point is to not use FTP
> since it is "insecure". The kewl people nowadays all use ssh/scp or some
> variant thereof. Any particular reason you aren't doing that too? Any
> reason you don't want all your friends to think you're kewl?

The reasons are quite mundane; ftp is primitive, it's the one I know,
no unnecessary complexity (remember my email-crypt-issue in another
thread), and it's only for transfers I do locally between different
devices at home.

What other folks think concerning my kewlness or whatnot isn't a theme
where I spend any neurons for.

Janis

On 29.01.2022 14:19, Ed Morton wrote:
> On 1/28/2022 2:29 PM, Janis Papanagnou wrote:
>> I have a shell script like the one depicted below as excerpt to invoke
>> simple ftp-transfers; the script invokes expect, and expect spawns ftp.
>> That script has issues with (today common) pathological file names.
>>
>> How would the correct quoting be done to pass the file with the below
>> depicted filename through all these nested tools?
>>
>>
>> server=...
>> file='A (pathological) file name w/ blanks, parenthesis, etc.pdf'
>
> Does updating it with printf '%q` get you to where you need to be:

There's different ways of quoting. What I already tried had been

file=$(quote "${file}")

where quote replaces the value by the single quoted value (as opposed
to escapes of individual characters). But no, it didn't help here.

>
> $ file='A (pathological) file name w/ blanks, parenthesis, etc.pdf'
> $ printf -v file '%q' "$file"

Unlike bash's, my printf has no -v, just BTW.

Janis

> $ echo "$file"
> A\ \(pathological\)\ file\ name\ w/\ blanks\,\ parenthesis\,\ etc.pdf
>
> Ed.

In article <st4biv$7af$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
....
>> $ file='A (pathological) file name w/ blanks, parenthesis, etc.pdf'
>> $ printf -v file '%q' "$file"
>
>Unlike bash's, my (I.e., ksh's) printf has no -v, just BTW.

Isn't -v just a shorthand for:

var=$(printf ...)

?

So, you would just use that instead.

What about %q? Does ksh have that? That also might be bash-specific -
but I don't know for sure...

--
The coronavirus is the first thing, in his 74 pathetic years of existence,
that the orange menace has come into contact with, that he couldn't browbeat,
bully, bullshit, bribe, sue, legally harrass, get Daddy to fix, get his
siblings to bail him out of, or, if all else fails, simply wish it away.

On 30.01.2022 04:49, Kenny McCormack wrote:
> In article <st4biv$7af$1@dont-email.me>,
> Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
> ...
>>> $ file='A (pathological) file name w/ blanks, parenthesis, etc.pdf'
>>> $ printf -v file '%q' "$file"
>>
>> Unlike bash's, my (I.e., ksh's) printf has no -v, just BTW.
>
> Isn't -v just a shorthand for:
>
> var=$(printf ...)

Effectively (maybe) yes, but I wouldn't bet on it, since the
subshell context or command composition may have side effects
that direct variable setting wouldn't have. (No coffee yet,
so I'm doing hard at the moment to think about samples, but I
think it's not bad to have a simple -v assignment available.)
Given that 'printf' is a builtin and $(...) of that builtin
will [in ksh] not create an extra process it's also not slow.

>
> ?
>
> So, you would just use that instead.

That's how we can do it with shells not supporting printf -v.
(The wrapper I used is effectively also just a printf, doing
var=$(quote ...), but consistently for all arguments not only
for those that need it in shell contexts.)

>
> What about %q? Does ksh have that? That also might be bash-specific -
> but I don't know for sure...

The %q is also in Ksh's printf. Beyond the ANSI specifiers, Ksh
supports %b %B %H %P %R %T %Z and %({csv|html|ere|pattern|url})q .
A couple of these are quite noteworthy - I don't know what bash
supports -, e.g. pattern conversions, CSV, HTML, URL conversions,
time formatting. There's also format modifiers to consider width
for characters instead of bytes/octets, and new ANSI escapes for
Unicode characters, scaling factors (1000 and 1024 based), digit
grouping, and a lot more.

Janis