RE: [Tcllib-devel] More file utilities ?

[Andreas K. <and...@Ac...>]

Hi Lars, long time no hear.

> Tisdag 31 januari 2006 kl 06.27 skrev Andreas Kupries:
> > I have (over time) collected a set of convenient commands operating
> > on/with whole files which seem to belong directly into either the
> > fileutil namespace, or a related namespace, like 'fileutil::FOO'.
> >
> > Unfortunately I also have trouble to find a proper name for FOO. Note
> > that we also might wish to change their names when they go into their
> > namespace, to remove redundancies ('file'), or have their final names
> > reflect their behavior more correctly (touch, hack_file).
>
> "contents", as suggested, feels appropriate to me (for all except
> [touch]).


> An argument for a separate namespace (and accordingly a separate
> package) is that code needing access to file contents in this manner
> don't always needs to manipulate metadata and vice versa, but I may be
> oversensitive there.

Not really. It is good to see this issue from so many angles.

> > 	getfile PATH
> >
> > 		Returns contents of file. Assumes that file is text,
> > 		and in system encoding.
>
> Then this is the same as [docstrip::util::thefile] (which I don't mind
> reducing to an alias), except that the latter one takes [fconfigure]
> options as well.

Heh. I have lots of places where I wrote 'getfile' and equivalent stuff to
make things convenient. Also note that tcltest's 'makeFile' for example is
'putfile', just with different argument order.


> Also, how is this different from [fileutil::cat]?

Oh. Oh. Thanks for the pointer. I quite forgot about this command.

... Reading docs ... Interesting. It is like 'getfile', but extended to
multiple files. Extending this to take fconfigure options between the file
names would make it a quite versatile file reader ...

Ok, time to think more about it.

> >
> > 		I.e. loads the file completely into memory
> >
> > 	putfile PATH TEXT
> >
> > 		Writes text as the new content of the file.
> > 		Note: Does _not_ add a traling \n to the data.
>
> [getfile] and [putfile] makes me think of the functionalities of
> [tk_getOpenFile] and [tk_getSaveFile] respectively, so I don't like
> these names. [fileutil::contents::get] and [fileutil::contents::put]
> feels OK, however.


> Also, should fileutil::contents be turned into an
> ensemble, then I'd much prefer

I am not thinking about doing them as an ensemble.

>
> > 	touch PATH
> >
> > 		Creates empty file at PATH. Deletes any pre-existing
> > 		file in this location.
>
> A [touch] already seems to be in fileutil, with an extensive number of
> options.

See my separate mail regarding touch.

> > 	hack_file PATH KEY VAL ...
> >
> > 		Takes the list of keys and values and applies them to
> > 		the contents of the file, via [string map].
>
> Do you mean
>
> 	hack_file PATH KEY VAL ?KEY VAL ...?
>
> here? Why not a dictionary argument, as in [string map]?

In the places where I needed/used this it was more natural to write the code
using var-args after the name of the file to modify.

	hack_file this/Makefile \
		this_wrong_stuff \
		the_correct_stuff \
		...


> In addition, the existing [fileutil::foreachLine] should perhaps be
> mentioned in this group. It too clearly deals with the contents of
> files.

I have to admit, I was not thinking about the existing commands in fileutil.
I would not like to touch (!) them right now, even if they would better
belong in the group of additional commands I proposed here, etc.

--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com, a division of Sophos
	Tel: +1 604 484 6491