sftp on openvms

[Steven Schweda]

> [...] Only -"v" results in the desired
> "verbose".

Really? Around here, only "-V" gives the
desired version report, even on my older
system:

alp2 $ tcpip show version

HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 7
on a COMPAQ Professional Workstation XP1000 running OpenVMS V7.3-2

alp2 $ sftp "-V"
alp2$dkb300:[sysa.syscommon.][sysexe]tcpip$ssh_sftp2.exe;1: SSH Secure Shell OpenVMS (V5.5) 3.2.0 on COMPAQ Professional Workstation - VMS V7.3-2

alp2 $ sftp "-v"
Sftp2/SFTP2.C:4804: CRTL version (SYS$SHARE:DECC$SHARE ident) is: V7.3-2-03

SshFileCopy/SSHFILECOPY.C:1062: Making local connection.
Ssh2SftpServer/SSHFILEXFERS.C:2079: Received SSH_FXP_INIT
Ssh2SftpServer/SSHFILEXFERS.C:2124: version is 3
SshFileCopy/SSHFILECOPY.C:1001: Connection to local, ready to serve requests.
Sftp2/SFTP2.C:786: Connection ready.
SshReadLine/SSHREADLINE.C:3662: Initializing ReadLine...
sftp> quit
SshReadLine/SSHREADLINE.C:3728: Uninitializing ReadLine...


alp2 $ sftp -V
Sftp2/SFTP2.C:4804: CRTL version (SYS$SHARE:DECC$SHARE ident) is: V7.3-2-03

SshFileCopy/SSHFILECOPY.C:1062: Making local connection.
[...]

alp2 $ sftp -v
Sftp2/SFTP2.C:4804: CRTL version (SYS$SHARE:DECC$SHARE ident) is: V7.3-2-03

SshFileCopy/SSHFILECOPY.C:1062: Making local connection.
[...]

But my C run-time environment is clean:

alp2 $ show logical decc$*

(LNM$PROCESS_TABLE)

(LNM$JOB_81811000)

(LNM$GROUP_000050)

(LNM$SYSTEM_TABLE)

"DECC$CRTLMAP" = "SYS$SHARE:DECC$SHR_EV56"
"DECC$SHR" = "SYS$SHARE:DECC$SHR_EV56"

(LNM$SYSCLUSTER_TABLE)

(DECW$LOGICAL_NAMES)
alp2 $

> Remove any DECC* logical names that might
> be around in the process or job context.
> Sufficiently odd settings for these can
> trigger errors in most any C application.

Generally good advice.

[Joseph Huber_1]

> Remove any DECC* logical names that might
> be around in the process or job context.
>Generally good advice.

And no, I WANT DECC$UNIX_LEVEL 30 to make all utils ported from U*x work.

It is the combination of SFTP DCL command-verb definition and DECC features, which defeats argv parsing.
I delete the sftp verb, and define sftp as an external command (sftp := $tcpip$ssh_sftp2) and can use the command as used on any other system without quoting anything.

Anyway for CHANDRASEKARANs question we need the verbose mode (either -v or -"v") to see where the error occurs.

[Hoff]

>It is the combination of SFTP DCL command-verb definition and DECC features, which defeats argv parsing.

Arguably, it is the non-modular and non-reentrant and moving-target "design" of the DECC$* logical name scheme.

This design is problematic now, it was problematic when originally designed, and it's increasingly problematic as the settings and the requirements continue to propagate and diverge and entrench and evolve. This stuff is (also) a dynamic environment as the RTLs are upgraded via ECO or via OpenVMS upgrades, or as the running settings are changed or as conflict arise as "other" stuff gets installed.

I'm now often adding the decc$feature_show_all() DEC C feature display call into the application signal handlers, so I can catch and display the current settings, and I'm starting to add logic in non-trivial applications to override the environmental settings; to suppress the logical names.

[Joseph Huber_1]

Hoff,
Yes, I agree.
In the case of ssh and sftp, it would be perfect to handle decc$ features inside the programs, but what it does simply makes it more confusing:
both have a CLD verb definition of

parameter P1 value (type=$rest_of_line)

i.e. DCL first converts everything not quoted to uppercase.
Then depending on DECC feature logicals one has to quote either the lower case options or the upper case ones.

In either case, a user can't use the syntax it is used from other systems.
A user working only in VMS might get used to use quotes, I don't, I work on a Linux desktop with terminal windows in VMS.

It is a matter of taste of course.
If I delete the useless ssh and sftp DCL verbs, replacing them by foreign command definitions, then with my usual DECC$UNIX_LEVEL 30 (or just DECC$ARGV_PARSE_STYLE ENABLE), I can use identical Linux and DCL commands.

I could live with ssh and sftp as is (usually I log into VMS, not from VMS into somewhere), but there are so many other GNU/Linux utilities ported without VMS command-line support, I don't remember the right quoting every time.

[Steven Schweda]

> And no, I WANT DECC$UNIX_LEVEL 30 to make
> all utils ported from U*x work.

That's one way. When I port a C program, I
normally add a LIB$INITIALIZE function to
set these things the way I want them. Then,
with Parse Style: Extended, I don't need to
think about them (until I go back to a VAX).
Why HP doesn't do the same thing with its own
products is a mystery to me.

Now, if someone would provide the cookbook to
show me how to do the same thing for a C++
program which hhijacks LIB$INITIALIZE for its
own purposes, ...

[Joseph Huber_1]

So we all agree that ssh/sftp command-line argument parsing is suboptimal,
back to topic:

CHANDRASEKARAN , do a verbose sftp:
sftp -"v" user@host
The resulting output should show at which point the error occurs.

[Steven Schweda]

> what does "SHOW SYMBOL SFTP" return ?

Don't forget "show logical DCL$PATH".

[Jay So]

Hi,

If you're missing SFTP as symbol, that's normal. However, you can have it defined for you by invoking @SYS$MANAGER:TCPIP$DEFINE_COMMANDS.COM

$ sftp*2 :== $'f$edit("sys$system:tcpip$ssh_sftp2.exe","upcase")'

And here's an example of using BATCH mode SFTP.

$ SET VERIFY
$! SFTP_BATCH.COM to submit SFTP to batch
$!
$! Set default to where SFTP.INPUT is located, otherwise,
$! SFTP command would have to use full path in unix style:
$! i.e. /sys$sysdevice/h_so/test/sftp.input
$ set def SYS$SYSDEVICE:[H_SO.TEST]
$!
$! Following gets output of the sftp commands to the log, without it,
$! none of the sftp output will be logged:
$ define/user sys$input sys$command
$!
$! The following logicals were for various tests:
$! define/process sys$output SYS$SYSDEVICE:[H_SO.TEST]sftp.output
$! define/process sys$error SYS$SYSDEVICE:[H_SO.TEST]sftp.output
$!
$! Following is the correct syntax for 5.4 ECO5 and higher:
$ sftp -"B" sftp.input localhost
$!
$! Following is the correct syntax for 5.4 ECO4 and below:
$! sftp -b sftp.input localhost
$!
$ exit

Where SFTP.INPUT file contains the following:
pwd
ls
get foosadjfhlo.txt
quit


Also note that SFTP.INPUT could contain multiple
open
close

with sftp commands inbetween:
i.e.
open host1
ls
get myfile.txt
close
open host2
get yourfile.txt
close
open host3
put myfile.txt yourfile.txt
close
quit

Regards,

Jay So

[Jay So]

I forgot to mention that ssh/sftp/scp in BATCH mode REQUIRES "passwordless" authentication such as publickey or hostbased:

From Tru64 Uninx # man SFTP

-B batchfile
Reads commands from a file instead of standard input. Because this mode
is intended for scripts or cron jobs, the sftp2 command will not try to
interact with the user, which means that only authentication methods
that do not use passwords will work. In batch mode, a failure to
change the current working directory will cause the sftp2 command to
abort. Other errors are ignored.

I believe this also means that keys with passphrases will also not work with batch mode...