× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



1) Specifically, what version of Open SSH has the issue?
2) I'm on openssh-4.7p1, which I think is current for V7R1.
3) Specifically, which PTFs were involved?


Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of craigs@xxxxxxxxx
Sent: Wednesday, August 13, 2014 11:12 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Fw: SFTP MGET new restrictions

Thanks Scott and Rob. You are right about the upgraded OpenSSH, Scott.
IBM responded that special characters must be escaped with the backslash (\). So, I tried the following in SFTP (GET identical to MGET):
GET "*" This gets the last file and names it *
GET '*' This gets the last file and names it *
GET "\*" This threw an error about did not find the file /dir/\\\\\\*
GET "G\*" This threw an error about did not find the file /dir/G\\\\\\*
GET "~*" This threw an error about did not find the file /dir/~\\*
GET * Gets all files in /dir as we already know and keeps the same
names.
GET "File 1"* Gets the files beginning /dir/'File 1' and keeps the same
names.
GET 'File 1'* Gets the files beginning '/dir/File 1' and keeps the same
names.

So, wildcards must not be in quotes and cannot be escaped to be part of the file name at least for the site I am testing. Why the problems with the escape? I think in Unix, the \ is the escape but Windows is ~. This particular site seems to be going to Windows but the ~ doesn't escape either. Yeah, I expect file not found for the escaped character but not those backslashes in the file name. I can make this work for now by throwing escape characters outside quotes instead of trying to escape them. This seems different than what IBM found on the OpenSSH website.
IBM said:
Hi Craig,
There was a discussion about this issue and I have cut and pasted a couple of the comments below for you, but the bottom line is that you will not be able to do the mget as you once did.

"I think the PTFs you loaded would have upgraded the version of OpenSSH being used, and in that new version (non IBM i specific) there were changes made to correct some issues with special characters in character strings and how they would be interpreted. As you have discovered, they now need to be ESCAPED using the slash character so ensure they are read correctly.

"Pathnames and file names containing spaces are supported, however they must be enclosed in double quotes. Since you are incorporating the wildcard character I think it is treating it as a string literal value on the mget command and thus attempting to run the stat() function to see if the file "*.zip" actually exists which of course a file by this specific name doesn't exist.

Here is some text from the sftp documentation on the OpenSSH website.

Pathnames that contain spaces must be enclosed in quotes. Any special characters contained within pathnames that are recognized by
glob(3) must be escaped with backslashes (‘\’). "

Please let me know if this answers your question and if I can be of more assistance.
Regards,

Patti Ryan
Software Engineer, IBMi GSC

Thanks,
Craig
----- Forwarded by Craig Strong/DEKKO on 08/13/2014 10:46 AM -----

From: Craig Strong/DEKKO
To: midrange-l@xxxxxxxxxxxx,
Date: 08/12/2014 01:34 PM
Subject: Fw: SFTP MGET new restrictions


I did more testing on the MGET "*" issue. I tried:
MGET * and got the file fine.
MGET *.txt and got the file fine.
MGET "*" and got the file renamed as *
MGET "*.txt" and got the file renamed as *.txt

So, double quotes and wildcards don't mix anymore. Anyone seen this before?

Thanks,
Craig
----- Forwarded by Craig Strong/DEKKO on 08/12/2014 01:30 PM -----

From: Craig Strong/DEKKO
To: midrange-l@xxxxxxxxxxxx,
Date: 08/12/2014 08:55 AM
Subject: SFTP MGET new restrictions


I would be able to perform the following for years in the QSHELL SFTP:
MGET "*"
After we moved to a new system with the same O/S and same directories including the /home directories, the MGET "*" still gets the files and data but names them * (single asterisk). Well, for this application there is almost always one file. The script and the O/S haven't changed. I know there are alternatives like expect scripts and doing ls -l to an outfile and updating the script dynamically. I would like to have this working like before which seems to be the desired functionality. The reason for double quotes is that I have a command that places the file to get in double quotes and uses GET or MGET depending on if an asterisk is present. I haven't tried MGET "*.txt" or something else yet because it is difficult to test with the customer.
Theories: SFTP setting file somewhere using defaults after the move to the new system. SFTP setting file authority has changed. New PTF restricting single asterisk not being allowed in double quotes.

Any ideas how to be able to use MGET "*" and keep the same names like before the system move?

Thanks,
Craig
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.