Re: Adding a 'D - date' option to 'cat'

From: Bill Vermillion <bv_at_wjv.com>
Date: Sat, 9 Sep 2006 11:24:39 -0400
While stranded on the shoulder of the Information
Superhiway and trying to flag down some passing bytes
freebsd-current-request_at_freebsd.org said "Bits don't fail me now",
and continued with:


> Date: Fri, 08 Sep 2006 16:35:16 -0700
> From: "Don L. Belcher" <don_at_siad.net>
> Subject: Re: Adding a 'D - Date' option to 'cat'

> I would like to weigh in here, with a different perspective on
> this issue.

> So maybe it is time to re-think what filters are and how they
> should work.

> Lets start with date, I would say date utility is the
> appropriate tool to use for adding date to the stream of data,
> but I have an issue with adding in all the parsing information.
> What would happen? At first only newline parsing would occur,
> but then somebody would come along and say "I would like to
> append date every third line", which would need another change
> to date to accomplish the task. This would happen several times
> over the years and in this way and I could see date becoming
> bloated for this reason.

If it's adding text to strings of text using a filter, how
about adding one more option to 'pr'.   I build large files of
identical lines - like the old teletype test lines for those of you
who remember then - and make the file 10,000 number lines long -
formatted for 14" wide paper.

I used to use this for testing remote printing that when through
about 4 serial ports - including muxes - on it's way to the final
destination.  It was the only way I could be sure that all the
flow-control in each device was talking to the other properly.
And I'd seen failure when I got to about 50K files - but if I could
pass this 10,000 line file through it was solid.  And using
numbering and identical lines made it easy to spot any errors.
With 22 printers in remote cities it became a neccesity.  Now that
we have TCP/IP all those problems are gone - thankfully.

Since PR will put in line numbers, an option to put a date in 
there instead of would seem perhaps an easy place to start.
You could make it 'in addition to' but it would give you a wide
printout.

> For instance if date did not have to parse the file and only had
> to append to an object ( as apposed to a stream of characters),
> then the date utility would only need append to the beginning
> or end of an object ( unless this functionality already exits )
> and would not need to worry about how to parse the information
> (which could be binary data for all the date utility would
> care).

> Yes this would be more complicated then for current filter
> system, but it also would have its advantages.

Sounds like 'pr' modification might be less complicated.

Bill
-- 
Bill Vermillion - bv _at_ wjv . com
Received on Sat Sep 09 2006 - 13:24:51 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:00 UTC