You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by steve cohen <sc...@javactivity.org> on 2003/12/30 14:14:42 UTC
[net] SYST/FTPClient.getSystemName()
[originally posted in a slightly different form on commons-dev, now
cross-posting to commons-user]
I am beginning the work of tying the selection of a specific
FTPFileEntryParser in commons-net to the output of the SYST command on that
system. (getSystemName() is a wrapper around SYST). The goal of this is to
enable clients of this code (such as Ant) to be able to select specific
parsers without tying themselves too closely to the internals of commons-net,
i.e., knowing the package names and class names of each of the parsers.
To that end, I would like to compile a list of SYST/getSystemName() outputs on
each of the different system types, so we can code a mapping for this.
Eventually, it may even lead to an auto-detect functionality.
I know that a default unix FTP server will return "UNIX". Will those who use
this code on other systems be so kind as to help me fill in this table?
Commons-Net Parser Type that Return Value
succesfully parses entries from getSystemName()
---------------------------- --------------------
UnixFTPEntryParser UNIX
NTFTPEntryParser ?
OS2FTPEntryParser ?
EnterpriseUnixFTPEntryParser ?
VMSFTPEntryParser ?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [net] SYST/FTPClient.getSystemName()
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
Here's another:
SUN OS 5.8: UNIX Type: L8 Version: SUNOS
>>>>> On Tue, 30 Dec 2003 07:16:05 -0600, steve cohen <sc...@javactivity.org> said:
> [originally posted in a slightly different form on commons-dev, now
> cross-posting to commons-user]
> I am beginning the work of tying the selection of a specific
> FTPFileEntryParser in commons-net to the output of the SYST command
> on that system. (getSystemName() is a wrapper around SYST). The
> goal of this is to enable clients of this code (such as Ant) to be
> able to select specific parsers without tying themselves too closely
> to the internals of commons-net, i.e., knowing the package names and
> class names of each of the parsers.
> To that end, I would like to compile a list of SYST/getSystemName()
> outputs on each of the different system types, so we can code a
> mapping for this. Eventually, it may even lead to an auto-detect
> functionality.
> I know that a default unix FTP server will return "UNIX". Will
> those who use this code on other systems be so kind as to help me
> fill in this table?
> Commons-Net Parser Type that Return Value succesfully parses entries
> from getSystemName() ----------------------------
> -------------------- UnixFTPEntryParser UNIX NTFTPEntryParser ?
> OS2FTPEntryParser ? EnterpriseUnixFTPEntryParser ?
> VMSFTPEntryParser ?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] SYST/FTPClient.getSystemName()
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
Bummer, I'll have to file that idea for potential future implementation.
Thanks for the great explanation of the issues involved.
>>>>> On Tue, 30 Dec 2003 12:57:27 -0600, steve cohen <sc...@javactivity.org> said:
> On Tuesday 30 December 2003 12:13 pm, Jeffrey D. Brekke wrote:
>> Two additional ideas:
>>
>> 1) What about defining one parser implementation, and having the
>> regular expressions vary based on system?
> This has come up before. I don't think it can work. The regex can
> break the input into groups, but there still needs to be CODE that
> recognizes that the third group represents the month and the fourth
> the year, etc. If regular expressions provided a way to NAME or
> otherwise identify the groups, we might be able to rock and roll but
> I don't believe that ORO provides this and neither does java 1.4's
> java.util.regex. I think I maybe once saw something like this in
> Perl or Python, but not in anything we can use here. But that's
> what it would take. Lacking that, CODE is necessary to provide the
> necessary CONTEXTUAL information needed to parse a regex into a data
> structure such as FTPFile.
> On the other hand, it's just a mapping. What is expressed as code
> such as this:
> String typeStr = group(1); String hardLinkCount =
> group(15); String usr = group(16); String grp = group(17); String
> filesize = group(18); String mo = group(19); String da = group(20);
> String yr = group(22); String hr = group(23); String min =
> group(24); String name = group(25); String endtoken = group(26);
> could be stored in some sort of table that is associated with the
> regex. But there are still problems with other bits of logic that
> live over and above regexes, such as the different parsing of dates
> based on whether the date falls within the current year or a past
> year (embodied in code as "if" statements), that make this
> problematical.
> So I think the effort level here is much more than you are
> imagining.
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] SYST/FTPClient.getSystemName()
Posted by steve cohen <sc...@javactivity.org>.
On Tuesday 30 December 2003 12:13 pm, Jeffrey D. Brekke wrote:
> Two additional ideas:
>
> 1) What about defining one parser implementation, and having the regular
> expressions vary based on system?
This has come up before. I don't think it can work. The regex can break the
input into groups, but there still needs to be CODE that recognizes that the
third group represents the month and the fourth the year, etc. If regular
expressions provided a way to NAME or otherwise identify the groups, we might
be able to rock and roll but I don't believe that ORO provides this and
neither does java 1.4's java.util.regex. I think I maybe once saw something
like this in Perl or Python, but not in anything we can use here. But that's
what it would take. Lacking that, CODE is necessary to provide the necessary
CONTEXTUAL information needed to parse a regex into a data structure such as
FTPFile.
On the other hand, it's just a mapping. What is expressed as code such as
this:
String typeStr = group(1);
String hardLinkCount = group(15);
String usr = group(16);
String grp = group(17);
String filesize = group(18);
String mo = group(19);
String da = group(20);
String yr = group(22);
String hr = group(23);
String min = group(24);
String name = group(25);
String endtoken = group(26);
could be stored in some sort of table that is associated with the regex. But
there are still problems with other bits of logic that live over and above
regexes, such as the different parsing of dates based on whether the date
falls within the current year or a past year (embodied in code as "if"
statements), that make this problematical.
So I think the effort level here is much more than you are imagining.
>
> 2) Use host name/ip address to also select the parser/RE. I was
> thinking then one could have a properties file or something setup with
> the parser to use ( off the top of my head, not much thought into this
> yet):
>
> default=UNIX
> VMS=[fq parser classname] or [ regular expression ]
> ...
> qdsvms.qgraph.com=VMS
> 192.1681.1.1=EnterpriseUnix
>
> Then if there is no specific host/ip listing, default to the system
> name mapping, else the default parser ( which could also be customized
> )?
This idea seems worthy of more attention. I think it holds promise.
>
> >>>>> On Tue, 30 Dec 2003 12:13:36 -0600, steve cohen
> >>>>> <sc...@javactivity.org> said:
> >
> > Well, it sounds like only OS2 and Enterprise Unix are problematical.
> > I Googled "OS2 FTP" and I can't find a single publicly accessible
> > FTP site that runs OS2. I did find this page:
> >
> > http://www.sentex.net/kwos2cug/os2-ftp.html
> >
> > which lists dozens of ftp sites RELATED to OS2. The majority of
> > them are defunct and those that are still live are running on unix
> > servers. But for now, it will be fine to use the "OS/2" key. If
> > anyone can provide more accurate information, please send it on and
> > we'll be happy to include it.
> >
> > As for "Enterprise Unix", since it doesn't seem to identify itself
> > as anything different from regular Unix, we won't be able to provide
> > auto-detection.
> >
> > What I am envisioning now is a factory method like this:
> >
> > public static FTPFileEntryParser createFileEntryParser(String key);
> >
> > where key could be either one of the known strings ("UNIX", "OS/2",
> > "Windows", or "VMS") or else a fully qualified class name of a class
> > that implements FTPFileEntryParser (to accomodate Enterprise Unix
> > and any user-written parsers that may be out there). If there are
> > other versions of these keys in existence, they, too can be allowed;
> > we can have a many to one mapping between keys and parsers.
> >
> > This API would be exposed to outside clients such as Ant. The ant
> > <ftp> task can be rewritten to have an additional attribute called,
> > say, "servertype" that the user can supply and the code rewritten to
> > instantiate this parser and use it. This method can also be the
> > guts behind an autodetection scheme yet to be written.
> >
> > On Tuesday 30 December 2003 08:58 am, Jeffrey D. Brekke wrote:
> >> For OS2 we check if the string OS/2 is present. For NT we check if
> >> the string Windows is present. For VMS we check if the string VMS
> >> is present.
> >>
> >> This way we don't have to mess with version numbers and stuff. The
> >> actual returns that I can verify are:
> >>
> >> AIX v5.1L: UNIX Type: L8 Version: BSD-44 Linux (Redhat/wu): UNIX
> >> Type: L8 OpenVMS: VMS OpenVMS V7.1 on node XXXXXX. Windows
> >> NT/2000: Windows_NT version 4.0 Windows_NT Windows_NT version 5.0
> >>
> >> The Enterprise for UNIX 1.2.05 Secure FTP server we've encountered
> >> also reports: UNIX Type: L8 and does not have a normal unix
> >> listing. That is why we needed to write a special parser for that
> >> one.
> >>
> >> We no longer have OS/2 servers available.
> >>
> >> >>>>> On Tue, 30 Dec 2003 07:16:05 -0600, steve cohen >>>>>
> >>
> >> <sc...@javactivity.org> said:
> >> > [originally posted in a slightly different form on commons-dev,
> >>
> >> now > cross-posting to commons-user]
> >>
> >> > I am beginning the work of tying the selection of a specific >
> >>
> >> FTPFileEntryParser in commons-net to the output of the SYST command
> >>
> >> > on that system. (getSystemName() is a wrapper around SYST). The
> >> > goal of this is to enable clients of this code (such as Ant) to
> >>
> >> be > able to select specific parsers without tying themselves too
> >> closely > to the internals of commons-net, i.e., knowing the
> >> package names and > class names of each of the parsers.
> >>
> >> > To that end, I would like to compile a list of
> >>
> >> SYST/getSystemName() > outputs on each of the different system
> >> types, so we can code a > mapping for this. Eventually, it may
> >> even lead to an auto-detect > functionality.
> >>
> >> > I know that a default unix FTP server will return "UNIX". Will >
> >>
> >> those who use this code on other systems be so kind as to help me >
> >> fill in this table?
> >>
> >> > Commons-Net Parser Type that Return Value succesfully parses
> >>
> >> entries > from getSystemName() ---------------------------- >
> >> -------------------- UnixFTPEntryParser UNIX NTFTPEntryParser ? >
> >> OS2FTPEntryParser ? EnterpriseUnixFTPEntryParser ? >
> >> VMSFTPEntryParser ?
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >>
> >> > To unsubscribe, e-mail:
> >>
> >> commons-dev-unsubscribe@jakarta.apache.org > For additional
> >> commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] SYST/FTPClient.getSystemName()
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
Two additional ideas:
1) What about defining one parser implementation, and having the regular
expressions vary based on system?
2) Use host name/ip address to also select the parser/RE. I was
thinking then one could have a properties file or something setup with
the parser to use ( off the top of my head, not much thought into this
yet):
default=UNIX
VMS=[fq parser classname] or [ regular expression ]
...
qdsvms.qgraph.com=VMS
192.1681.1.1=EnterpriseUnix
Then if there is no specific host/ip listing, default to the system
name mapping, else the default parser ( which could also be customized
)?
>>>>> On Tue, 30 Dec 2003 12:13:36 -0600, steve cohen <sc...@javactivity.org> said:
> Well, it sounds like only OS2 and Enterprise Unix are problematical.
> I Googled "OS2 FTP" and I can't find a single publicly accessible
> FTP site that runs OS2. I did find this page:
> http://www.sentex.net/kwos2cug/os2-ftp.html
> which lists dozens of ftp sites RELATED to OS2. The majority of
> them are defunct and those that are still live are running on unix
> servers. But for now, it will be fine to use the "OS/2" key. If
> anyone can provide more accurate information, please send it on and
> we'll be happy to include it.
> As for "Enterprise Unix", since it doesn't seem to identify itself
> as anything different from regular Unix, we won't be able to provide
> auto-detection.
> What I am envisioning now is a factory method like this:
> public static FTPFileEntryParser createFileEntryParser(String key);
> where key could be either one of the known strings ("UNIX", "OS/2",
> "Windows", or "VMS") or else a fully qualified class name of a class
> that implements FTPFileEntryParser (to accomodate Enterprise Unix
> and any user-written parsers that may be out there). If there are
> other versions of these keys in existence, they, too can be allowed;
> we can have a many to one mapping between keys and parsers.
> This API would be exposed to outside clients such as Ant. The ant
> <ftp> task can be rewritten to have an additional attribute called,
> say, "servertype" that the user can supply and the code rewritten to
> instantiate this parser and use it. This method can also be the
> guts behind an autodetection scheme yet to be written.
> On Tuesday 30 December 2003 08:58 am, Jeffrey D. Brekke wrote:
>> For OS2 we check if the string OS/2 is present. For NT we check if
>> the string Windows is present. For VMS we check if the string VMS
>> is present.
>>
>> This way we don't have to mess with version numbers and stuff. The
>> actual returns that I can verify are:
>>
>> AIX v5.1L: UNIX Type: L8 Version: BSD-44 Linux (Redhat/wu): UNIX
>> Type: L8 OpenVMS: VMS OpenVMS V7.1 on node XXXXXX. Windows
>> NT/2000: Windows_NT version 4.0 Windows_NT Windows_NT version 5.0
>>
>> The Enterprise for UNIX 1.2.05 Secure FTP server we've encountered
>> also reports: UNIX Type: L8 and does not have a normal unix
>> listing. That is why we needed to write a special parser for that
>> one.
>>
>> We no longer have OS/2 servers available.
>>
>> >>>>> On Tue, 30 Dec 2003 07:16:05 -0600, steve cohen >>>>>
>> <sc...@javactivity.org> said:
>> >
>> > [originally posted in a slightly different form on commons-dev,
>> now > cross-posting to commons-user]
>> >
>> > I am beginning the work of tying the selection of a specific >
>> FTPFileEntryParser in commons-net to the output of the SYST command
>> > on that system. (getSystemName() is a wrapper around SYST). The
>> > goal of this is to enable clients of this code (such as Ant) to
>> be > able to select specific parsers without tying themselves too
>> closely > to the internals of commons-net, i.e., knowing the
>> package names and > class names of each of the parsers.
>> >
>> > To that end, I would like to compile a list of
>> SYST/getSystemName() > outputs on each of the different system
>> types, so we can code a > mapping for this. Eventually, it may
>> even lead to an auto-detect > functionality.
>> >
>> > I know that a default unix FTP server will return "UNIX". Will >
>> those who use this code on other systems be so kind as to help me >
>> fill in this table?
>> >
>> > Commons-Net Parser Type that Return Value succesfully parses
>> entries > from getSystemName() ---------------------------- >
>> -------------------- UnixFTPEntryParser UNIX NTFTPEntryParser ? >
>> OS2FTPEntryParser ? EnterpriseUnixFTPEntryParser ? >
>> VMSFTPEntryParser ?
>> >
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail:
>> commons-dev-unsubscribe@jakarta.apache.org > For additional
>> commands, e-mail: commons-dev-help@jakarta.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] SYST/FTPClient.getSystemName()
Posted by steve cohen <sc...@javactivity.org>.
Two things, one immediately and one after this is developed:
1) Please tell me the output of the SYST command when you are logged onto your
OS/2 servers. If different servers behave differently to this command, show
all different responses.
2) When this is developed we may ask you to test. Thanks.
Steve Cohen
On Tuesday 30 December 2003 12:30 pm, Noel J. Bergman wrote:
> We can probably provide testing for OS/2. What would you need? Our
> remaining OS/2 servers are not publically exposed to the Internet.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [net] SYST/FTPClient.getSystemName()
Posted by "Noel J. Bergman" <no...@devtech.com>.
We can probably provide testing for OS/2. What would you need? Our
remaining OS/2 servers are not publically exposed to the Internet.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] SYST/FTPClient.getSystemName()
Posted by Steve Cohen <st...@comcast.net>.
Well, it sounds like only OS2 and Enterprise Unix are problematical.
I Googled "OS2 FTP" and I can't find a single publicly accessible FTP site
that runs OS2. I did find this page:
http://www.sentex.net/kwos2cug/os2-ftp.html
which lists dozens of ftp sites RELATED to OS2. The majority of them are
defunct and those that are still live are running on unix servers. But for
now, it will be fine to use the "OS/2" key. If anyone can provide more
accurate information, please send it on and we'll be happy to include it.
As for "Enterprise Unix", since it doesn't seem to identify itself as anything
different from regular Unix, we won't be able to provide auto-detection.
What I am envisioning now is a factory method like this:
public static FTPFileEntryParser createFileEntryParser(String key);
where key could be either one of the known strings ("UNIX", "OS/2", "Windows",
or "VMS") or else a fully qualified class name of a class that implements
FTPFileEntryParser (to accomodate Enterprise Unix and any user-written
parsers that may be out there). If there are other versions of these keys in
existence, they, too can be allowed; we can have a many to one mapping
between keys and parsers.
This API would be exposed to outside clients such as Ant. The ant <ftp> task
can be rewritten to have an additional attribute called, say, "servertype"
that the user can supply and the code rewritten to instantiate this parser
and use it. This method can also be the guts behind an autodetection scheme
yet to be written.
On Tuesday 30 December 2003 08:58 am, Jeffrey D. Brekke wrote:
> For OS2 we check if the string OS/2 is present.
> For NT we check if the string Windows is present.
> For VMS we check if the string VMS is present.
>
> This way we don't have to mess with version numbers and stuff. The
> actual returns that I can verify are:
>
> AIX v5.1L: UNIX Type: L8 Version: BSD-44
> Linux (Redhat/wu): UNIX Type: L8
> OpenVMS: VMS OpenVMS V7.1 on node XXXXXX.
> Windows NT/2000: Windows_NT version 4.0
> Windows_NT
> Windows_NT version 5.0
>
> The Enterprise for UNIX 1.2.05 Secure FTP server we've encountered
> also reports: UNIX Type: L8 and does not have a normal unix listing.
> That is why we needed to write a special parser for that one.
>
> We no longer have OS/2 servers available.
>
> >>>>> On Tue, 30 Dec 2003 07:16:05 -0600, steve cohen
> >>>>> <sc...@javactivity.org> said:
> >
> > [originally posted in a slightly different form on commons-dev, now
> > cross-posting to commons-user]
> >
> > I am beginning the work of tying the selection of a specific
> > FTPFileEntryParser in commons-net to the output of the SYST command
> > on that system. (getSystemName() is a wrapper around SYST). The
> > goal of this is to enable clients of this code (such as Ant) to be
> > able to select specific parsers without tying themselves too closely
> > to the internals of commons-net, i.e., knowing the package names and
> > class names of each of the parsers.
> >
> > To that end, I would like to compile a list of SYST/getSystemName()
> > outputs on each of the different system types, so we can code a
> > mapping for this. Eventually, it may even lead to an auto-detect
> > functionality.
> >
> > I know that a default unix FTP server will return "UNIX". Will
> > those who use this code on other systems be so kind as to help me
> > fill in this table?
> >
> > Commons-Net Parser Type that Return Value succesfully parses entries
> > from getSystemName() ----------------------------
> > -------------------- UnixFTPEntryParser UNIX NTFTPEntryParser ?
> > OS2FTPEntryParser ? EnterpriseUnixFTPEntryParser ?
> > VMSFTPEntryParser ?
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] SYST/FTPClient.getSystemName()
Posted by steve cohen <sc...@javactivity.org>.
Well, it sounds like only OS2 and Enterprise Unix are problematical.
I Googled "OS2 FTP" and I can't find a single publicly accessible FTP site
that runs OS2. I did find this page:
http://www.sentex.net/kwos2cug/os2-ftp.html
which lists dozens of ftp sites RELATED to OS2. The majority of them are
defunct and those that are still live are running on unix servers. But for
now, it will be fine to use the "OS/2" key. If anyone can provide more
accurate information, please send it on and we'll be happy to include it.
As for "Enterprise Unix", since it doesn't seem to identify itself as anything
different from regular Unix, we won't be able to provide auto-detection.
What I am envisioning now is a factory method like this:
public static FTPFileEntryParser createFileEntryParser(String key);
where key could be either one of the known strings ("UNIX", "OS/2", "Windows",
or "VMS") or else a fully qualified class name of a class that implements
FTPFileEntryParser (to accomodate Enterprise Unix and any user-written
parsers that may be out there). If there are other versions of these keys in
existence, they, too can be allowed; we can have a many to one mapping
between keys and parsers.
This API would be exposed to outside clients such as Ant. The ant <ftp> task
can be rewritten to have an additional attribute called, say, "servertype"
that the user can supply and the code rewritten to instantiate this parser
and use it. This method can also be the guts behind an autodetection scheme
yet to be written.
On Tuesday 30 December 2003 08:58 am, Jeffrey D. Brekke wrote:
> For OS2 we check if the string OS/2 is present.
> For NT we check if the string Windows is present.
> For VMS we check if the string VMS is present.
>
> This way we don't have to mess with version numbers and stuff. The
> actual returns that I can verify are:
>
> AIX v5.1L: UNIX Type: L8 Version: BSD-44
> Linux (Redhat/wu): UNIX Type: L8
> OpenVMS: VMS OpenVMS V7.1 on node XXXXXX.
> Windows NT/2000: Windows_NT version 4.0
> Windows_NT
> Windows_NT version 5.0
>
> The Enterprise for UNIX 1.2.05 Secure FTP server we've encountered
> also reports: UNIX Type: L8 and does not have a normal unix listing.
> That is why we needed to write a special parser for that one.
>
> We no longer have OS/2 servers available.
>
> >>>>> On Tue, 30 Dec 2003 07:16:05 -0600, steve cohen
> >>>>> <sc...@javactivity.org> said:
> >
> > [originally posted in a slightly different form on commons-dev, now
> > cross-posting to commons-user]
> >
> > I am beginning the work of tying the selection of a specific
> > FTPFileEntryParser in commons-net to the output of the SYST command
> > on that system. (getSystemName() is a wrapper around SYST). The
> > goal of this is to enable clients of this code (such as Ant) to be
> > able to select specific parsers without tying themselves too closely
> > to the internals of commons-net, i.e., knowing the package names and
> > class names of each of the parsers.
> >
> > To that end, I would like to compile a list of SYST/getSystemName()
> > outputs on each of the different system types, so we can code a
> > mapping for this. Eventually, it may even lead to an auto-detect
> > functionality.
> >
> > I know that a default unix FTP server will return "UNIX". Will
> > those who use this code on other systems be so kind as to help me
> > fill in this table?
> >
> > Commons-Net Parser Type that Return Value succesfully parses entries
> > from getSystemName() ----------------------------
> > -------------------- UnixFTPEntryParser UNIX NTFTPEntryParser ?
> > OS2FTPEntryParser ? EnterpriseUnixFTPEntryParser ?
> > VMSFTPEntryParser ?
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] SYST/FTPClient.getSystemName()
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
For OS2 we check if the string OS/2 is present.
For NT we check if the string Windows is present.
For VMS we check if the string VMS is present.
This way we don't have to mess with version numbers and stuff. The
actual returns that I can verify are:
AIX v5.1L: UNIX Type: L8 Version: BSD-44
Linux (Redhat/wu): UNIX Type: L8
OpenVMS: VMS OpenVMS V7.1 on node XXXXXX.
Windows NT/2000: Windows_NT version 4.0
Windows_NT
Windows_NT version 5.0
The Enterprise for UNIX 1.2.05 Secure FTP server we've encountered
also reports: UNIX Type: L8 and does not have a normal unix listing.
That is why we needed to write a special parser for that one.
We no longer have OS/2 servers available.
>>>>> On Tue, 30 Dec 2003 07:16:05 -0600, steve cohen <sc...@javactivity.org> said:
> [originally posted in a slightly different form on commons-dev, now
> cross-posting to commons-user]
> I am beginning the work of tying the selection of a specific
> FTPFileEntryParser in commons-net to the output of the SYST command
> on that system. (getSystemName() is a wrapper around SYST). The
> goal of this is to enable clients of this code (such as Ant) to be
> able to select specific parsers without tying themselves too closely
> to the internals of commons-net, i.e., knowing the package names and
> class names of each of the parsers.
> To that end, I would like to compile a list of SYST/getSystemName()
> outputs on each of the different system types, so we can code a
> mapping for this. Eventually, it may even lead to an auto-detect
> functionality.
> I know that a default unix FTP server will return "UNIX". Will
> those who use this code on other systems be so kind as to help me
> fill in this table?
> Commons-Net Parser Type that Return Value succesfully parses entries
> from getSystemName() ----------------------------
> -------------------- UnixFTPEntryParser UNIX NTFTPEntryParser ?
> OS2FTPEntryParser ? EnterpriseUnixFTPEntryParser ?
> VMSFTPEntryParser ?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org