tcllib-devel

RE: [Tcllib-devel] More file utilities ? [touch]

[Jeff H. <je...@Ac...>]

Andreas Kupries wrote:
> Having slept on this I believe the proper name for the 
> described functionality is 'clear'.
> 
> 	If the file exists, clear its contents, make it empty.
> 	And if it doesn't exist, create it as empty.
> 
> Hemang's comment about creating the directory leading to the 
> file is correct however. I agree that this is something the 
> command should do, given my description. This was no problem 
> for me so far because it was not used in context where the 
> directory would not exist.

Please provide an example of this that this isn't better
handled with:
	set fd [open $filename w]

Jeff

RE: [Tcllib-devel] More file utilities ? [touch]

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

> Andreas Kupries wrote:
> > Having slept on this I believe the proper name for the
> > described functionality is 'clear'.
> >
> > 	If the file exists, clear its contents, make it empty.
> > 	And if it doesn't exist, create it as empty.
> >
> > Hemang's comment about creating the directory leading to the
> > file is correct however. I agree that this is something the
> > command should do, given my description. This was no problem
> > for me so far because it was not used in context where the
> > directory would not exist.
>
> Please provide an example of this that this isn't better
> handled with:
> 	set fd [open $filename w]

Heh. Just 'grep'd the sources and find that while the command is in the
fu.tcl package here, it is not used anywhere :(

Hm. It can be seens as 'create an empty' file, or 'truncate an existing'
file. In the second case, well, 8.5. will have a 'ftruncate' command. And
for the first case it is likely that the file will be filled with data
immediately after. So keeping it open makes more sense than closing it and
then using 'appendto' etc. to change it.

Jeff has an argument here. We apparently do not really need this one.

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

Re: [Tcllib-devel] More file utilities ? [touch]

[Hemang L. <hl...@ci...>]

Andreas Kupries wrote:
>> Andreas Kupries wrote:
>>     
>>> Having slept on this I believe the proper name for the
>>> described functionality is 'clear'.
>>>
>>> 	If the file exists, clear its contents, make it empty.
>>> 	And if it doesn't exist, create it as empty.
>>>       
You can use the proposed fileutil::write cmd with empty TEXT to do this.
If you want to really make it convenient, let the TEXT argument be
optional, so that one can simply call:

::fileutil::write /tmp/xxx

Hemang.

Re: [Tcllib-devel] More file utilities ?

[Joe E. <jen...@fl...>]

Andreas Kupries wrote:

> 	touch PATH
> 		Creates empty file at PATH. Deletes any pre-existing
> 		file in this location.

For Unix users, "touch" would be a _very bad_ name for this operation --
the shell command `touch` only updates the modification time
of existing files, it doesn't truncate them.


> 	getfile PATH
> 		Returns contents of file. Assumes that file is text,
> 		and in system encoding.
> 	putfile PATH TEXT
> 		Writes text as the new content of the file.
> 		Note: Does _not_ add a traling \n to the data.

I usually call these "readFile" and "writeFile", after
the analogous Haskell Standard Prelude functions.


> 	insertat PATH AT DATA
> 		Inserts data at offset AT into the file.
>
> 	removeat PATH AT N
> 		Removes N characters from the file, starting at
> 		offset AT.

No comment on the names, but these operations would be
very useful to have in tcllib just so we'd have a short
answer when newbies ask how to do this (which seems to
come up once a month or so on c.l.t. :-)


> 	hack_file PATH KEY VAL ...
> 		Takes the list of keys and values and applies them to
> 		the contents of the file, via [string map].
>
> 	hack_file_copy PATHin PATHout KEY VAL ...
> 		Like hack_file, but writes the result to a different
> 		file.

These seem rather special-purpose.  A useful factor of the
first one might be:

	updateInPlace $filename $cmdPrefix --
	    Reads the contents of file $filename and passes it
	    as an additional argument to $cmdPrefix.  Overwrites
	    the original file with the return value of the command.
	    If the command raises an error, the original file
	    is not modified.

Then 'hack_file' could be expressed as:

	updateInPlace PATH [list string map [list KEY VAL...]]



--Joe English

  jen...@fl...

RE: [Tcllib-devel] More file utilities ?

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

> Andreas Kupries wrote:
>
> > 	touch PATH
> > 		Creates empty file at PATH. Deletes any pre-existing
> > 		file in this location.
>
> For Unix users, "touch" would be a _very bad_ name for this operation --
> the shell command `touch` only updates the modification time
> of existing files, it doesn't truncate them.

See the recent discussion. clearf/truncate, etc. And arguments that we do
not need this command at all.


> > 	getfile PATH
> > 		Returns contents of file. Assumes that file is text,
> > 		and in system encoding.
> > 	putfile PATH TEXT
> > 		Writes text as the new content of the file.
> > 		Note: Does _not_ add a traling \n to the data.
>
> I usually call these "readFile" and "writeFile", after
> the analogous Haskell Standard Prelude functions.

Ok, and another proposal for the names :)

> > 	insertat PATH AT DATA
> > 		Inserts data at offset AT into the file.
> >
> > 	removeat PATH AT N
> > 		Removes N characters from the file, starting at
> > 		offset AT.
>
> No comment on the names

My latest thoughts are to name them 'insert', 'remove', 'replace'.

>, but these operations would be
> very useful to have in tcllib just so we'd have a short
> answer when newbies ask how to do this (which seems to
> come up once a month or so on c.l.t. :-)

:)

> > 	hack_file PATH KEY VAL ...
> > 		Takes the list of keys and values and applies them to
> > 		the contents of the file, via [string map].

> > 	hack_file_copy PATHin PATHout KEY VAL ...
> > 		Like hack_file, but writes the result to a different
> > 		file.

> These seem rather special-purpose.  A useful factor of the
> first one might be:

> 	updateInPlace $filename $cmdPrefix --
> 	    Reads the contents of file $filename and passes it
> 	    as an additional argument to $cmdPrefix.  Overwrites
> 	    the original file with the return value of the command.
> 	    If the command raises an error, the original file
> 	    is not modified.
>
> Then 'hack_file' could be expressed as:
>
> 	updateInPlace PATH [list string map [list KEY VAL...]]

The current implementation of hack_file is, in essence:

	proc hack_file {path args} {
	    putfile $path [string map $args [getfile $path]]
	}

Your proposal strikes me as a nice generalization of this. Thanks.

hack_file_copy is a bit redundant anyway. It can be expressed as 'file copy
+ hack_file', although writing it directly as get/map/put with different
paths might be more efficient.

Hm. updateInPlace, I was putting some 'patch' commands into the collection,
similar to the hack_file, but not quite (only one key to replace, but
multiple values, for each occurence of the key). Bianry patching anyone ?
Well, your proposal covers this as well, just a different update command ...
Yes, this seems to be the generally useful core.

Note: slightly OT, because this is not about the new commands, but an
existing one ... We have some proposals for extending fileutil::find in the
tracker (see RFEs). I thought yesterday that we can handle that by exposing
the core of going through a dir-hierarchy via a 'traversal' command taking
options.


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

Re: [Tcllib-devel] More file utilities ?

[Damon C. <da...@tc...>]

Joe English wrote:
> Andreas Kupries wrote:
>
>   
>> 	touch PATH
>> 		Creates empty file at PATH. Deletes any pre-existing
>> 		file in this location.
>>     
>
> For Unix users, "touch" would be a _very bad_ name for this operation --
> the shell command `touch` only updates the modification time
> of existing files, it doesn't truncate them.
>   

    And creates them if they don't exist.  I actually think touch is 
very useful, but only if it conforms to what the UNIX touch already 
does.  As Joe stated, it definitely DOES NOT truncate or delete a file.

Damon