Parsing file names with spaces
in [Perl]
|
From: sln on 1 Jul 2010 17:10 On Thu, 1 Jul 2010 18:02:15 +0200, "Peter J. Holzer" <hjp-usenet2(a)hjp.at> wrote: >On 2010-07-01 11:14, Justin C <justin.0911(a)purestblue.com> wrote: >> On 2010-07-01, Uri Guttman <uri(a)StemSystems.com> wrote: >>>>>>>> "BM" == Ben Morrow <ben(a)morrow.me.uk> writes: >>> >>> BM> ls -l output intentionally uses fixed-width columns, except for the >>> BM> filename. So >>> >>> normally that is true, but very large files can cause the name column to >>> be shifted over. some ls flavors or options will change the size to use >>> a suffix but you can't count on fixed width there. as i posted it is >>> best to assume fixed width until the size but that is always a number >>> with a possible size suffix so it is easy to match and the rest is the >>> file name. >> >> An observation (that may be erroneous) of the output of ls: The second >> to last field is always the time, which contains a colon. > >Not true. If the file is older than 6 months, this field will be the >year. But something like > >($stuff_before_date, $date, $filename) = > m/ > (.*) \040 > ((?: Jan | Feb | ... | Dec) \d\d (?: \d\d:\d\d | \d\d\d\d) ) \040 > (.*) > /x; > >might work. Of course the output of ls depends on the locale, so it >might be completely different, but if we want to parse every possible >output of ls the problem becomes intractable, so you need to make some >assumptions, like "locale is known" or "user and group names don't >contain spaces" or "fields are lined up". To take advantage of the >last property you need to check all the lines to detect vertical >columns. > Increasingly, it becomes evident that fields may be the easiest to maintain but certainly not a fix. The date as an anchor for the filename may be more reliable, but the locale could present issues. So in the spirit of split, something via regex maybe? /\s* (?: \S+ \040+ ){8} ([^\040\n] .* \040 .* [^\040\n]) \n/x -sln
From: Ilya Zakharevich on 1 Jul 2010 18:25 On 2010-07-01, Peter J. Holzer <hjp-usenet2(a)hjp.at> wrote: > I disagree. He should have mentioned that and quite a few things more > (for example the different date formats, whether user and group names > are always numeric, and if not, whether they can contain spaces, etc.) > > Test data is nice but you can never assume that it covers all possible > cases and requirements reverse engineered from a few lines of test > data are almost guaranteed to be incomplete. Besides, why should > everyone in this group have to figure out the requirements when the OP > can do it once? I think that now you realized that your arguments lead you to a contradiction. This thread provided tons of useful information about how the OP's requirements MIGHT look like. Armed with this list of possible complications, NOW the OP is in the position of answering the question about which of these complications might appear in his listings. And I consider it very probable that before these contributions, the OP could not formulate his requirements JUST BEFORE HE DID NOT REALIZE THESE COMPLICATIONS (as I missed the considerations of the user/group names and locales when I first read his post). ==== In general, I consider the pipe dream of "formulate the requirements first, then code to specification" very counter-productive; most probably, it is one of the principal tumbling blocks in the contemporary state of the programming. It may work in a handful of toy situations, but it does not scale up to "what really happens". Software designers should be ready to changes-in-specification when new information is gathered by pilot implementations. They should be ready to advise ASAP the clients on possible pitfalls in the pilot specifications, etc. Yours, Ilya
From: Steve M on 4 Jul 2010 20:37 On 7/1/2010 3:25 PM, Ilya Zakharevich wrote: > On 2010-07-01, Peter J. Holzer<hjp-usenet2(a)hjp.at> wrote: >> I disagree. He should have mentioned that and quite a few things more >> (for example the different date formats, whether user and group names >> are always numeric, and if not, whether they can contain spaces, etc.) >> >> Test data is nice but you can never assume that it covers all possible >> cases and requirements reverse engineered from a few lines of test >> data are almost guaranteed to be incomplete. Besides, why should >> everyone in this group have to figure out the requirements when the OP >> can do it once? > > I think that now you realized that your arguments lead you to a > contradiction. This thread provided tons of useful information about > how the OP's requirements MIGHT look like. Armed with this list of > possible complications, NOW the OP is in the position of answering the > question about which of these complications might appear in his listings. > > And I consider it very probable that before these contributions, the > OP could not formulate his requirements JUST BEFORE HE DID NOT REALIZE > THESE COMPLICATIONS (as I missed the considerations of the user/group > names and locales when I first read his post). > > ==== > > In general, I consider the pipe dream of "formulate the requirements > first, then code to specification" very counter-productive; most > probably, it is one of the principal tumbling blocks in the > contemporary state of the programming. It may work in a handful of > toy situations, but it does not scale up to "what really happens". > > Software designers should be ready to changes-in-specification when > new information is gathered by pilot implementations. They should be > ready to advise ASAP the clients on possible pitfalls in the pilot > specifications, etc. > Here, here! (roar of applause in the background) \s -- "There is no use in your walking five miles to fish when you can depend on being just as unsuccessful near home." M. Twain
From: John Kelly on 4 Jul 2010 21:12 On Sun, 04 Jul 2010 17:37:08 -0700, Steve M <stevem_clipthis_(a)clubtrout.com> wrote: >On 7/1/2010 3:25 PM, Ilya Zakharevich wrote: >> In general, I consider the pipe dream of "formulate the requirements >> first, then code to specification" very counter-productive; most >> probably, it is one of the principal tumbling blocks in the >> contemporary state of the programming. It may work in a handful of >> toy situations, but it does not scale up to "what really happens". >> Software designers should be ready to changes-in-specification when >> new information is gathered by pilot implementations. They should be >> ready to advise ASAP the clients on possible pitfalls in the pilot >> specifications, etc. >Here, here! (roar of applause in the background) Encore! -- Web mail, POP3, and SMTP http://www.beewyz.com/freeaccounts.php
From: Martijn Lievaart on 5 Jul 2010 01:29
On Thu, 01 Jul 2010 22:25:41 +0000, Ilya Zakharevich wrote: > In general, I consider the pipe dream of "formulate the requirements > first, then code to specification" very counter-productive; most > probably, it is one of the principal tumbling blocks in the contemporary > state of the programming. It may work in a handful of toy situations, > but it does not scale up to "what really happens". That is why one of the cardinal rules of Prince II project management is "Requirements change". > Software designers should be ready to changes-in-specification when new > information is gathered by pilot implementations. They should be ready > to advise ASAP the clients on possible pitfalls in the pilot > specifications, etc. Encapsulation and loose coupling are your friends here. Well written components encapsulate the requirements and are easy to change. M4 |