Re: Nvu

[Simon Coulter <shc@xxxxxxxxxxxxxxxxx>]

On 24/10/2006, at 4:43 AM, web400@xxxxxxxxxxxxxxxx wrote:

> Hello,
>
> > I initially thought this might be caused by the default naming format
> > but I have my systems set to use the Unix listing format and naming
> > format so I installed the Mac version of Nvu and got the same stupid
> > error.
>
> It is due to the format of the directory list (not naming.)  And since
> there's no standard for this format, Nvu has a problem... it needs code
> that understands every possible format on earth :)

No, it just needs to presume the default is Unix which as far as I can 
tell is standard. All the Unix servers I tried give the same layout for 
the directory listing.

I've used other graphical FTP clients that had no specific support for 
OS/400 and they've worked fine even in the days before we got IFS 
naming format and Unix directory listing format options so it can be 
done in a manner most likely to succeed.

I accept that they need specific parsing code for non-Unix servers like 
VMS or WinDOS but the bulk will be Unix. Notice that BSD and MACOS are 
both Unix servers but return different remote server type strings. 
OS/400 is in the same position. They should all work with standard Unix 
directory listing output. It shouldn't require code changes to support 
a new Unix-type server.

> The developers therefore have code to understand the most common 
> formats.
> They send the SYST command to the FTP server, and it tells them which 
> FTP
> server it's running.  Then it distills that into the various directory
> listing formats (Unix, Windows, et al)

That's what I was expecting (and what I guessed in my previous note 
when I said they check the response from the server after login and 
reject those they don't know about).

> It took me about 5 minutes to find this out by first using Ethereal to
> discover that it's using the SYST command to check the server type, and
> then using GREP to search for the SYST command in the source code.
>
> I found the following source file:
>
>     netwerk/protocol/ftp/src/nsFtpConnectionThread.cpp

Your search was more successful than mine.

> In that source there's a method named nsFtpState::R_syst() that 
> appears to
> be where the response is coming from.
> It does this:
>
> FTP_STATE
> nsFtpState::R_syst() {
>      if (mResponseCode/100 == 2) {
>          if (( mResponseMsg.Find("L8") > -1) ||
>              ( mResponseMsg.Find("UNIX") > -1) ||
>              ( mResponseMsg.Find("BSD") > -1) ||
>              ( mResponseMsg.Find("MACOS Peter's Server") > -1) ||
>              ( mResponseMsg.Find("MVS") > -1) ||
>              ( mResponseMsg.Find("OS/390") > -1))
>          {
>              mServerType = FTP_UNIX_TYPE;
>          }
>          else if ( ( mResponseMsg.Find("WIN32", PR_TRUE) > -1) ||
>                    ( mResponseMsg.Find("windows", PR_TRUE) > -1) )
>          {
>              mServerType = FTP_NT_TYPE;
>          }
>          else if ( mResponseMsg.Find("OS/2", PR_TRUE) > -1)
>          {
>              mServerType = FTP_OS2_TYPE;
>          }
>          else if ( mResponseMsg.Find("VMS", PR_TRUE) > -1)
>          {
>              mServerType = FTP_VMS_TYPE;
>          }
>          else
>          {
>              NS_ASSERTION(0, "Server type list format unrecognized.");

And the rest of the code shows:
            NS_ASSERTION(0, "Server type list format unrecognized.");
            // Guessing causes crashes.
            // (Of course, the parsing code should be more robust...)

which I rather think proves the point I make below. Even if it gets a 
listing format it doesn't understand the worst that should happen is 
uploads or downloads fail. And that's presuming it uses the listing 
format. As far as I can tell from the Nvu dialogues it doesn't. It 
expects the user to provide a path for publishing (perhaps once it gets 
connected to a server it understands it behaves differently).

[[ Ahh, now that I get a successful login (see below) I can see that 
the right-hand pane can show a directory listing. The Publish icon 
prompts for a password if not supplied in the settings but this pane 
just gives "Login incorrect". Saving the password and retrying gives 
the same error. Quitting Nvu and restarting makes it work. Kiddies 
writing software ... ]]

> That's as far as I was able to get in 5 minutes.  From here, I'm going 
> to
> try adding OS/400 just after MVS and recompile.  Of course, it'll only
> work if the i5/OS FTP server is set to Unix directory format, and 
> namefmt
> 1 by default, but it'll be a good test.

Which would be an acceptable requirement--especially for a utility that 
doesn't specifically understand OS/400.

> If that works, I can try to take
> it a step further and make it insert the commands to change the 
> directory
> and name format on-the-fly.
>
> > Rather stupid of Nvu because FTP is FTP. Although FTP servers usually
> > have extras the lowest common denominator is the same. If they don't
> > recognise the server they should just presume Unix and carry on.
>
> First of all...  there's absolutely no standard for the format of the
> directory listing.  It's intended to be "human readable" so there's no
> need to standardize it.  Personally, I think that was a big mistake in 
> the
> design of the protocol.  It should've been given well-defined fields 
> for
> each element returned in the directory listing, and if the client 
> wants it
> to be nice for a person to read, it can format it appropriately.
>
> But as it is, you either get one filename per line without any further
> detail (which is standardized) or you get "human-readable output" that 
> can
> be in any format, but typically contains dates, file sizes, and other
> information that you can't get from the "just filenames" format.

When you set the OS/400 FTP server to use *UNIX listing format you get 
output that matches what a Unix FTP server would provide. Therefore IF 
the authors of the Nvu FTP client were sensible they could use the UNIX 
type as the default and hey, it would work. Or better yet given that 
the bulk of the FTP servers available are Unix types allow the Unix 
server type strings to be externally defined then they could satisfy 
both the safety aspects by rejecting "unknown" servers AND allow a user 
to specify that a supposedly unknown server will work.

The authors don't need to be aware of OS/400. They just need to think a 
bit more about supporting other Unix-y servers. Still, in typical 
open-source fashion the solution is "just change the code".

> Anyway, I'll add OS/400 and recompile and let the list know what I 
> come up
> with.

I just tried this and get build errors:
checking for GLIB - version >= 1.2.0... no
*** The glib-config script installed by GLIB could not be found
*** If GLIB was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the GLIB_CONFIG environment variable to the
*** full path to glib-config.
checking for libIDL-config... no
checking for libIDL - version >= 0.6.3... no
*** The libIDL-config script installed by libIDL could not be found
*** If libIDL was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the LIBIDL_CONFIG environment variable to the
*** full path to libIDL-config.
checking for orbit-config... no
configure: error: libIDL not found.
        libIDL 0.6.3 or higher is required.
*** Fix above errors and then restart with "make -f client.mk build"

So now we enter the "open source maze" again. Now I have to find and 
install GLIB and libIDL (and whatever dependencies they have) and go 
again. Like I said earlier, I've got better things to do with my time. 
Google finds both for me quickly enough but doesn't help with the time 
to download, install, rebuild. Maybe I'll do this when I'm bored, it 
would be nice to have an HTML editor that worked on MacOS X and 
understood OS/400.

Again, if the Nvu developers had allowed the Unix server strings to be 
externalised they could be set to include OS/400 and Jon would be off 
working without all this messing around.

As a test I changed the text of the TCP error messages I mentioned in 
my previous append to replace "OS/400" wit "UNIX" and guess what? 
Successful connection. However the upload fails with "501 Unknown 
extension in database file name" which is what usually occurs when 
naming format is 0 however my systems have naming format 1 (*PATH) by 
default but they do use *CURLIB as the default home directory. I had to 
also configure FTP to set the initial directory to *HOMEDIR and end and 
restart FTP to get past this. Then I get "426-Unable to open or create 
file /home/SHC/home/shc/nvu/nvu.html". Notice the double occurrence of 
/home/shc ? So back to the NVU parameters and change the ftp path from 
ftp://gryphon/home/shc/nvu to ftp://gryphon/nvu (which makes no sense) 
but that gives "426-Unable to open or create file 
/home/SHC/nvu/nvu.html" even though both *PUBLIC and the ID being used 
have *RWX to the complete path. Creating the file first then gives 426 
with yet another messed up path.

Downloading a file seems to work but publishing it still gives 426 with 
a messed up path. Ahh, file had no HTML content. Downloading a file 
with HTML content displays in Nvu, and can be changed, and can be 
published (although the specified path cannot include the home 
directory). So nett result is that if the code is changed to handle 
"OS/400" as a valid server string or the TCP messages are changed to 
say UNIX it will work. Time to start some real work instead of messing 
with amateur code.

Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists

   http://www.flybynight.com.au/
   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175                                   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------