parsing a response line from sysfiletree

ooRexx 3.2.0 (6.02, 30 Oct 2007) under Win XP

Suppose a response line from a sysfiletree call looks like

yyyy-mm-dd hh:mm:ss 0 -D--- C:\a.b.c.d.e f.g.h

how do people generally chop this up? It seems to me that

parse var stem.n ymd hms siz att fnm .

works well, returning each value with no leading or trailing blanks - but of
course the fnm value is wrong if there were spaces in the filename. Trying

parse var stem.n ymd hms siz att fnm

works except the last var, fnm, ends up with a leading space. So do people
generally do

parse var stem.n ymd hms siz att" "fnm

instead? This doesn't seem to me to adhere to the Principle of Least
Astonishment.





--
Jeremy C B Nicoll - my opinions are my own.

Jeremy Nicoll - news posts wrote:
> works except the last var, fnm, ends up with a leading space. So do people
> generally do
>
> parse var stem.n ymd hms siz att" "fnm

Neat duct tape! ;-) Saving that to my KB.

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/

Jeremy Nicoll - news posts wrote:
> ooRexx 3.2.0 (6.02, 30 Oct 2007) under Win XP
>
> Suppose a response line from a sysfiletree call looks like
>
> yyyy-mm-dd hh:mm:ss 0 -D--- C:\a.b.c.d.e f.g.h
>
> how do people generally chop this up? It seems to me that
>
> parse var stem.n ymd hms siz att fnm .
>
> works well, returning each value with no leading or trailing blanks - but of
> course the fnm value is wrong if there were spaces in the filename. Trying
>
> parse var stem.n ymd hms siz att fnm
>
> works except the last var, fnm, ends up with a leading space. So do people
> generally do
>
> parse var stem.n ymd hms siz att" "fnm
>
> instead? This doesn't seem to me to adhere to the Principle of Least
> Astonishment.
>
>
>
>
>
As the problem - the leading blank on the file name - is a result of the
double blank preceding the file name, why not use

parse value space(stem.n) with ymd hms siz att fnm

HTH...

In Message-ID:<AeKdnSBZv5q4SfPVnZ2dnUVZ_s3inZ2d@pronetisp.net >,
Gil Barmwater <gil_b@bellsouth.net> wrote:

>As the problem - the leading blank on the file name - is a result of the
>double blank preceding the file name, why not use
>
>parse value space(stem.n) with ymd hms siz att fnm

Because file "a b c" is different from file "a b c". Screen
scraping (with some dross left out):

23:36 Fri 2008-07-04 F:\>dir
Directory of F:\
2008-07-04 23:36 12 a b c
2008-07-04 23:36 11 a b c
2 File(s) 23 bytes

--
Arthur T. - ar23hur "at" intergate "dot" com
Looking for a z/OS (IBM mainframe) systems programmer position

In Message-ID:<egAbk.18$rb6.17@newsfe02.lga>,
Michael Lueck <mlueck@lueckdatasystems.com> wrote:

>Jeremy Nicoll - news posts wrote:
>> works except the last var, fnm, ends up with a leading space. So do people
>> generally do
>>
>> parse var stem.n ymd hms siz att" "fnm
>
>Neat duct tape! ;-) Saving that to my KB.

Take it back out of your KB, it doesn't work.

When parsing, REXX will first find literals and make
substrings before and after. Then it parses those substrings.
So, the first " " splits the string and *everything* following
will be assigned to fnm (with most of the other variables being
assigned null).

You're pretty much required to use two statements if you want
to get rid of leading blanks from the last variable in a parse. I
agree with the OP that it violates the law of least astonishment,
but it's how it's documented.

--
Arthur T. - ar23hur "at" intergate "dot" com
Looking for a z/OS (IBM mainframe) systems programmer position

> yyyy-mm-dd hh:mm:ss 0 -D--- C:\a.b.c.d.e f.g.h
>
> how do people generally chop this up? It seems to me that
>
> parse var stem.n ymd hms siz att fnm .


I normally go for:

Parse value subword(stem.n,1,4) subword(stem.n,5)
with date time size attrs filename

Thus the only blanks that I have to worry about are leading blanks in
the filename. I've never come across a file so named; I'm not sure it
would be legal on most systems, and it would surely be asking for trouble.

--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

In Message-ID:<48704e41@news.greennet.net>,
Steve Swift <Steve.J.Swift@gmail.com> wrote:

>> yyyy-mm-dd hh:mm:ss 0 -D--- C:\a.b.c.d.e f.g.h
>>
>> how do people generally chop this up? It seems to me that
>>
>> parse var stem.n ymd hms siz att fnm .
>
>
>I normally go for:
>
>Parse value subword(stem.n,1,4) subword(stem.n,5)
> with date time size attrs filename
>
>Thus the only blanks that I have to worry about are leading blanks in
>the filename. I've never come across a file so named; I'm not sure it
>would be legal on most systems, and it would surely be asking for trouble.

Asking for trouble, certainly. Illegal, I'm afraid not:

1:22 Sat 2008-07-05 F:\>dir *b*
Directory of F:\
2008-07-04 23:36 12 a b c
2008-07-04 23:36 11 a b c
2008-07-05 01:20 0 abc
2008-07-05 01:20 0 a bc
2008-07-05 01:20 0 abc
2008-07-05 01:22 0 abc

System is Win2K. I expect it's equally legal (and equally a
bad idea) on any Win system which supports long filenames.

--
Arthur T. - ar23hur "at" intergate "dot" com
Looking for a z/OS (IBM mainframe) systems programmer position

Gil Barmwater <gil_b@bellsouth.net> wrote:

> As the problem - the leading blank on the file name - is a result of the
> double blank preceding the file name, why not use
>
> parse value space(stem.n) with ymd hms siz att fnm

Because it destroys multiple embedded blanks in filenames. It's bad enough
(I think) that Windows has spaces in filenames at all (I'm more used to RISC
OS which lets people type in spaces but converts them to ascii 160 ie a hard
space internally, so filenames are still single 'words').


I dislike seeing filenames in proportional fonts, and have on occasion used
multiple spaces to try to align sets of filenames better. So eg I have some
notes files in one directory which when listed with 'dir' look a bit like:

disk-C b scratch file tidyup - done 20080624 .txt
disk-C c cleanup - done 20080624 .txt
disk-C d error-check - done 20080624 .txt
disk-C e defrag - done 20080624 .txt
disk-C f full backup to SEA1 - done 20080407 .txt
disk-C f full backup to SEA2 - done 20080407 .txt
disk-SEA1 a error-check - done 20080406 .txt
disk-SEA1 b defrag - done 20080406 .txt
disk-SEA2 a error-check - done 20080406 .txt
disk-SEA2 b defrag - done 20080406 .txt

but when I see them in Windows Explorer they look more like:

disk-C b scratch file tidyup - done 20080624 .txt
disk-C c cleanup - done 20080624 .txt
disk-C d error-check - done 20080624 .txt
disk-C e defrag - done 20080624 .txt
disk-C f full backup to SEA1 - done 20080407 .txt
disk-C f full backup to SEA2 - done 20080407 .txt
disk-SEA1 a error-check - done 20080406 .txt
disk-SEA1 b defrag - done 20080406 .txt
disk-SEA2 a error-check - done 20080406 .txt
disk-SEA2 b defrag - done 20080406 .txt

That is, they're not perfectly aligned, but it's better than it would be
without judicious extra spaces in the filenames.

--
Jeremy C B Nicoll - my opinions are my own.

Steve Swift <Steve.J.Swift@gmail.com> wrote:

> > yyyy-mm-dd hh:mm:ss 0 -D--- C:\a.b.c.d.e f.g.h
> >
> > how do people generally chop this up? It seems to me that
> >
> > parse var stem.n ymd hms siz att fnm .
>
>
> I normally go for:
>
> Parse value subword(stem.n,1,4) subword(stem.n,5)
> with date time size attrs filename

Thanks for this suggestion.


> Thus the only blanks that I have to worry about are leading blanks in
> the filename. I've never come across a file so named; I'm not sure it
> would be legal on most systems, and it would surely be asking for trouble.

Hell! I seriously mistyped that filename - nearly all the dots were meant
to be backslashes ie I meant:

C:\a\b\c\d\e f\g.h

This comes from using a machine with dots as the 'directory' separator a lot
of the time, where filenames look like:

ADFS::4.$.This.That and.The Other.Prog 2/Rexx

and for anyone who's interested I've written a bit more about that system
below.



This's in ex-Acorn's RISC OS. In those names, what looks like a space eg
between the "That" and "and" in "That and", or "Prog" and "2" in the
leafname, is held in the file system as a hard-space (ascii 160) so the
whole name parses as a single token. Typically - with a Regina rexx port on
that system - I break those into successive levels by translating all the
dots to spaces then using words() and subword() to select chosen parts, then
if needed translate spaces back to dots.

When someone is naming/renaming a file the RO gui translates the ordinary
space character(s) that they type into the 160s.

Under RO, files don't have type-specific file extensions. Instead there's a
three digit hex value stored as metadata by the filesystem. Internally RO
just uses that to categorise files. Plain "data" files have filetype
x'000', text is x'fff', jpegs are 'c85', and so on. There's a default set
of system variables eg

File$Type_C85 has value "JPEG"

A simple command:

Set File$Type_C85 Piccie

would result in all jpeg files being listed in directory displays etc as eg

My Picture Piccie
His photo Piccie

though there are also variants of the directory display commands which will
show filetypes in hex. File system commands will take filetype parameters
either in text form or as eg "&FFF" form.

The same method is used for "file associations". When you double click a
file the system looks at a system variable, eg for jpegs:

Alias@RunType_C85

to find the command to be used to 'run' a jpeg. Merely listing all the
system variables shows you the current set of all the associations, and many
other things too.

--
Jeremy C B Nicoll - my opinions are my own.

Arthur T. <arthur@munged.invalid> wrote:

> In Message-ID:<egAbk.18$rb6.17@newsfe02.lga>,
> Michael Lueck <mlueck@lueckdatasystems.com> wrote:
>
> >Jeremy Nicoll - news posts wrote:

> >> parse var stem.n ymd hms siz att" "fnm
> >
> >Neat duct tape! ;-) Saving that to my KB.
>
> Take it back out of your KB, it doesn't work.

So it doesn't! Well, tie me to a tree and call me Brenda!
(as a friend used to say).

Clearly it's time I reread the chapter on parse.



> You're pretty much required to use two statements if you want
> to get rid of leading blanks from the last variable in a parse. I
> agree with the OP that it violates the law of least astonishment,
> but it's how it's documented.

Actually, what really surprises me is that the values on each line aren't
just single-space separated, leaving reformatting of the lines to the caller
if they wanted to do so.

Also, I wonder how the designers decided how wide the size column should be?
Any fixed limit is going to be too small eventually. It doesn't get wider
if you set a big 'numeric digits' value, either.


--
Jeremy C B Nicoll - my opinions are my own.