From: John Kelly on 1 Jul 2010 11:38
On Thu, 01 Jul 2010 11:31:49 -0400, Sherm Pendley
>John Kelly <jak(a)isp2dial.com> writes:
>> Of course I realize that does little to assuage the social thirst of the
>> dominant clique here.
>Boo hoo. Whine much?
You just couldn't resist could you.
"While snarlers strive with proud but fruitless pain
To wound immortals, or to slay the slain."
Web mail, POP3, and SMTP
From: Peter J. Holzer on 1 Jul 2010 12:02
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) =
((?: Jan | Feb | ... | Dec) \d\d (?: \d\d:\d\d | \d\d\d\d) ) \040
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
From: Tad McClellan on 1 Jul 2010 12:24
John Kelly <jak(a)isp2dial.com> wrote:
> On Thu, 01 Jul 2010 11:31:49 -0400, Sherm Pendley
>>John Kelly <jak(a)isp2dial.com> writes:
>>> Of course I realize that does little to assuage the social thirst of the
>>> dominant clique here.
>>Boo hoo. Whine much?
> You just couldn't resist could you.
*you* just couldn't resist, could you?
Your followup partially quoted above was a decent contribution
to the group... until you had to inject your bile at the end.
You reap what you sow.
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
From: Peter J. Holzer on 1 Jul 2010 12:41
On 2010-07-01 03:46, John Kelly <jak(a)isp2dial.com> wrote:
> On Wed, 30 Jun 2010 23:26:59 -0400, "Uri Guttman" <uri(a)StemSystems.com>
[nothing of importance]
Can you two please take your bickering elsewhere? This is getting
From: Jim Gibson on 1 Jul 2010 12:44
In article <j4vn26110qd9p89ai9tngmr4o43eia26pb(a)4ax.com>, J�rgen Exner
> "Uri Guttman" <uri(a)StemSystems.com> wrote:
> >that is just poor code. do you want to count the undefs each time you do
> >something like that? and why is that last line checking for space? he
> >wants all the file names.
> That is not what the OP said. He explicitely said:
> "I want to extract just the file which contain spaces"
> To me that excludes filenames without spaces.
Unfortunately, "file which contain spaces" is incorrect English and
ambiguous. The phrase should be either:
1. "file names that contain spaces"
2. "file names, which can contain spaces"
"that" is "restrictive" here and means only file names that include
spaces are wanted, while "which" is "non-restrictive" and means that
all file names are wanted, but some may contain spaces. Note the
difference in punctuation.
While this sounds like a nit-pick, it does influence the code, as we