tcllib-devel — Discussion of development for tcllib

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

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 ?

[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...

Reply-To settings (was: [Tcllib-devel] More file utilities ?)

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

> > > BTW, how about setting the "reply-to list" option for this mailing
> > > list?
> >
> > It isn't ?
>
> No, the mails that come via the list don't have a Reply-To header that
> points back to the list.
>
> > It might be that the LookOut is not recognizing it. I am manually
> > trimming the receiver-list when responding, might have forgotten for
> > one of my replies.
>
> If the list was setting a Reply-To header you probably wouldn't need
> to manually adjust the receiver-list. Just tell AusGuck to reply to
> the Reply-To address only, if it is capable of doing that.

https://lists.sourceforge.net/lists/admin/tcllib-devel/?VARHELP=general/repl
y_goes_to_list

I am not sure if regular people can read this, so I will quote it below.
Currently the list is going with the recommendation of 'Poster'.

<quote>
Tcllib-devel Mailing list Configuration Help
reply_goes_to_list Option
reply_goes_to_list (general): Where are replies to list messages directed?
Poster is strongly recommended for most mailing lists.

This option controls what Mailman does to the Reply-To: header in messages
flowing through this mailing list. When set to Poster, no Reply-To: header
is added by Mailman, although if one is present in the original message, it
is not stripped. Setting this value to either This list or Explicit address
causes Mailman to insert a specific Reply-To: header in all messages,
overriding the header in the original message if necessary (Explicit address
inserts the value of reply_to_address).

There are many reasons not to introduce or override the Reply-To: header.
One is that some posters depend on their own Reply-To: settings to convey
their valid return address. Another is that modifying Reply-To: makes it
much more difficult to send private replies. See `Reply-To' Munging
Considered Harmful for a general discussion of this issue. See Reply-To
Munging Considered Useful for a dissenting opinion.

Some mailing lists have restricted posting privileges, with a parallel list
devoted to discussions. Examples are `patches' or `checkin' lists, where
software changes are posted by a revision control system, but discussion
about the changes occurs on a developers mailing list. To support these
types of mailing lists, select Explicit address and set the Reply-To:
address below to point to the parallel list.

Where are replies to list messages directed? Poster is strongly recommended
for most mailing lists.

Poster 	This list 	Explicit address

Warning: changing this option here could cause other screens to be
out-of-sync. Be sure to reload any other pages that are displaying this
option for this mailing list. You can also return to the general options
page.
<quote/>

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

RE: [Tcllib-devel] More file utilities ?

[Reinhard M. <ma...@tc...>]

Hi,

On Tue, 31 Jan 2006 at 10:00, Andreas Kupries wrote:

> From Lars we have that these commands are about manipulating the 
> contents of files, whereas the existing ones are not about directly 
> content, or at less so (His reference to 'cat' underminded that 
> argument a bit).

... and there are more existing commands that read the contents of 
files: fileType, foreachLine, and grep. Some even create files or 
change their content, albeit not with data that comes from the calling 
script: install, touch, and tempfile.

So we already have a mix of commands that read or write files, and 
others that only operate on directories, paths or file names.

> > Wasn't it the default recommendation for library writers to use 
> > qualified names instead of importing everything?
> 
> Library users you mean, I guess.

Both ;)

I meant people writing libraries that use existing libraries, as 
opposed to people writing applications that use libraries.

> This rings a bell, albeit not very hard. If you can find a reference 
> to this please post.

Maybe it was only discussed on the chat. I am not sure if I ever read 
it in a formalized or even archived way anywhere.

> > BTW, how about setting the "reply-to list" option for this mailing 
> > list?
> 
> It isn't ?

No, the mails that come via the list don't have a Reply-To header that 
points back to the list.

> It might be that the LookOut is not recognizing it. I am manually 
> trimming the receiver-list when responding, might have forgotten for 
> one of my replies.

If the list was setting a Reply-To header you probably wouldn't need 
to manually adjust the receiver-list. Just tell AusGuck to reply to 
the Reply-To address only, if it is capable of doing that.

cu
	Reinhard

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 ?

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

> Hi,
>
> On Tue, 31 Jan 2006 at 09:31, Andreas Kupries wrote:
>
> > > I see no need here to make the command names even longer by adding
> > > a level of sub-namespaces.
> >
> > I am not convinced of that argument for not using a namespace.
>
> And what was the argument again for using a new namespace?

None from me so far. From Lars we have that these commands are about
manipulating the contents of files, whereas the existing ones are not about
directly content, or at less so (His reference to 'cat' underminded that
argument a bit).

> > We can always use 'namespace export/import' + aliases to create
> > short names.
>
> My understanding was that [namespace import] needs to be used with
> care, because it might lead to confusion, especially if the new procs
> have names like [read] and [write] that exist in the global namespace
> already and might exist in other namespaces as well.

True.

> Wasn't it the default recommendation for library writers to use
> qualified names instead of importing everything?

Library users you mean, I guess. This rings a bell, albeit not very hard. If
you can find a reference to this please post.

> I like the fact that Tcl is much more explicit and verbose than
> languages like Perl, but I think we have to take care that we don't
> overstress this feature by creating long paths of nested namespaces
> unless they are really necessary,

Heh.

> which I don't see in this case.

I haven't made any decision yet. I will now digest all the opinions and
comments for a day or two and then come up with the next iteration of the
proposal, maybe even manpages.

>
> BTW, how about setting the "reply-to list" option for this mailing
> list?

It isn't ? It might be that the LookOut is not recognizing it. I am manually
trimming the receiver-list when responding, might have forgotten for one of
my replies.


--
	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]

[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 ?

[Reinhard M. <ma...@tc...>]

Hi,

On Tue, 31 Jan 2006 at 09:31, Andreas Kupries wrote:

> > I see no need here to make the command names even longer by adding 
> > a level of sub-namespaces.
> 
> I am not convinced of that argument for not using a namespace.

And what was the argument again for using a new namespace?

> We can always use 'namespace export/import' + aliases to create 
> short names.

My understanding was that [namespace import] needs to be used with 
care, because it might lead to confusion, especially if the new procs 
have names like [read] and [write] that exist in the global namespace 
already and might exist in other namespaces as well.

Wasn't it the default recommendation for library writers to use 
qualified names instead of importing everything?

I like the fact that Tcl is much more explicit and verbose than 
languages like Perl, but I think we have to take care that we don't 
overstress this feature by creating long paths of nested namespaces 
unless they are really necessary, which I don't see in this case.


BTW, how about setting the "reply-to list" option for this mailing 
list?


cu
	Reinhard

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

RE: [Tcllib-devel] More file utilities ?

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

> On Tue, 31 Jan 2006 at 13:18, Neil Madden wrote:
>
> > I'd vote for directly into the "fileutil" namespace.
>
> me too. I see no need here to make the command names even longer by
> adding a level of sub-namespaces.

I am not convinced of that argument for not using a namespace. We can always
use 'namespace export/import' + aliases to create short names.

> > Perhaps mapfile or filemap or even just map (i.e. [fileutil::map])
> > as it is quite similar to [string map]? The copy version can be done
> > as an option: fileutil map -copy $outfile $infile key val ...
>
> How about this signature?
>
> fileutil::map {key value ...} infile ?outfile?

> It would be a mixture of [string map] (regarding the mapping list) and
> [regsub] (regarding the optional "to" argument).

I like that signature ... Noted now.


>
> Off-topic remark:

This is for c.l.t., or tcl-core. Having said that, my opinion: No, I do not
think so.

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

RE: [Tcllib-devel] More file utilities ?

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

> Hi Andreas,
> 
> I would also vote for fileutils namespace. Suggestions for few proc
> names are:
> 
> getfile  -> ::fileutil::read
> putfile  -> ::fileutil::write
> appendto -> ::fileutil::append
> 
> As others have mentioned, touch should not delete the file.

See my other mail regarding 'touch'.

> Also, will
> it create the parent directory if it doesn't exist? I think it should.
 
That makes sense.

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

RE: [Tcllib-devel] More file utilities ?

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

>
> I'd vote for directly into the "fileutil" namespace.

Noted.

> > 	getfile PATH
> >
> > 		Returns contents of file. Assumes that file is text,
> > 		and in system encoding.
> >
> > 		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.
>
> Perhaps these can be extended to take options like -encoding
> -translation etc (some suitable subset of [chan configure] options)?

Yes, handling of -encoding and -translation, maybe -eofchar are logical
extensions.

> >
> > 	touch PATH
> >
> > 		Creates empty file at PATH. Deletes any pre-existing
> > 		file in this location.
>
> I'm with Mark G. Saye on this one -- if it's called "touch" it shouldn't
> delete a pre-existing file, but just update its atime/mtime.

See my separate mail regarding 'touch'.

> >
> > 	appendto PATH DATA
> > 	insertat PATH AT DATA
> > 	removeat PATH AT N

> Again, perhaps [chan configure] options are relevant here?

Yes, to all.

> >
> > 	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.
>
> Perhaps mapfile or filemap or even just map (i.e. [fileutil::map]) as it
> is quite similar to [string map]? The copy version can be done as an
> option: fileutil map -copy $outfile $infile key val ...

I see. Noted. I came up with 'strmap' during my sleep. I had 'subst' pop
into my head as well, but rejected that one.

Thanks for the comments.

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

RE: [Tcllib-devel] More file utilities ?

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

Andreas Kupries wrote:
> I like 'contents'. I see that many others like placing 
> everything directly into 'fileutil' as well.

Put me in the direct 'fileutil' camp.

Jeff

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 ?

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

> >	touch PATH
> >
> >		Creates empty file at PATH. Deletes any pre-existing
> >		file in this location.
> >
> >
> I believe fileutil::touch (or whatever) should be compatible with unix
> 'touch' comand and NOT delete an existing file - it should only "Update
> the access and modification times of each FILE to the current
> time.existing file"
>
> Also, the touch command is the only one which does not change the
> contents of a file, and maybe should be in a different namespace/package ?

See my separate mail regarding 'touch'.

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

RE: [Tcllib-devel] More file utilities ?

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

> > 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'.
> >
>
> These commands all seem to deal with the _contents_ of the files
> whereas the fileutil commands deal with meta-information about
> the files. Perhaps: fileutil::contents as a namespace?
> (I do not think a new module would be appropriate)

I like 'contents'. I see that many others like placing everything directly
into 'fileutil' as well.

--
	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]

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

Ok, all of you commenting on [touch] are heading into the wrong direction.

I provided a name and a functionality, and you are now apparently trying to
change the functionality to match the name, or pointing out that we have
'touch' ion fileutil already. I asked, albeit apparently not very clearly,
to _change the name_ of the command to match the functionality.

I quote:

> have their final names
> reflect their behavior more correctly (touch, hack_file).

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.


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

Re: [Tcllib-devel] More file utilities ?

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

Mark G. Saye wrote:
> Andreas Kupries wrote:
>>     touch PATH
>>
>>         Creates empty file at PATH. Deletes any pre-existing
>>         file in this location.
>>
> I believe fileutil::touch (or whatever) should be compatible with unix 
> 'touch' comand and NOT delete an existing file - it should only "Update 
> the access and modification times of each FILE to the current 
> time.existing file"

We already have this functionality in part in 'file mtime', so
I guess this adds just creating an non-existing file.  That
should definitely be in fileutil.

-- 
   Jeff Hobbs, The Tcl Guy
   http://www.ActiveState.com/, a division of Sophos

Re: [Tcllib-devel] More file utilities ?

[<Lar...@re...>]

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=20
[touch]).

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

oversensitive there.

> Below are the commands collected so far. I would like to get opinions
> on whether these commands should really be put into Tcllib, and if
> yes, where.
>
> 	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=20=

reducing to an alias), except that the latter one takes [fconfigure]=20
options as well.

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

>
> 		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=20
[tk_getOpenFile] and [tk_getSaveFile] respectively, so I don't like=20
these names. [fileutil::contents::get] and [fileutil::contents::put]=20
feels OK, however. Also, should fileutil::contents be turned into an=20
ensemble, then I'd much prefer

    fileutil::contents get ...
    fileutil::contents put ...


> 	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=20=

options.

> 	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 addition, the existing [fileutil::foreachLine] should perhaps be=20
mentioned in this group. It too clearly deals with the contents of=20
files.

Lars Hellstr=F6m=

[Tcllib-devel] RFC: Combobox autopost

[<ta...@jt...>]

Attached below is a proposed patch to the BWidget ComboBox.  It adds a
new feature, '-autopost', that automatically posts the combobox as the
user is typing into the entry.  Furthermore, it will scroll the
drop-down to entry that most closely matches the user's input.  I
believe my key bindings work as expected: cursor down/up to change the
selection, escape to unpost the widget.  Please comment -- and more
importantly, test -- the patch.  Thanks.

Sample code:

$ wish
% package require BWidget
1.7
% source combobox.tcl
% set entries {alpha beta beta1 beta2 beta22}
alpha beta beta1 beta2 beta22
% ComboBox .cb -autopost 1 -values $entries
.cb
% pack .cb

--- bwidget/combobox.tcl	2006-01-31 09:38:41.000000000 -0500
+++ bwidget-foo/combobox.tcl	2006-01-31 09:38:56.000000000 -0500
@@ -39,6 +39,7 @@ namespace eval ComboBox {
 	{-postcommand  String	  ""   0}
 	{-expand       Enum	  none 0 {none tab}}
 	{-autocomplete Boolean	  0    0}
+        {-autopost     Boolean    0    0}
         {-bwlistbox    Boolean    0    0}
         {-listboxwidth Int        0    0}
         {-hottrack     Boolean    0    0}
@@ -92,6 +93,13 @@ proc ComboBox::create { path args } {
 	::bind $path.e <KeyRelease> [list $path _auto_complete %K]
     }
 
+    if {[Widget::cget $path -autopost]} {
+        ::bind $path.e <KeyRelease> +[list $path _auto_post %K]
+    } else {
+        ::bind $entry <Key-Up>	  [list ComboBox::_unmapliste $path]
+        ::bind $entry <Key-Down>  [list ComboBox::_mapliste $path]
+    }
+
     if {[string equal $::tcl_platform(platform) "unix"]} {
 	set ipadx 0
 	set width 11
@@ -122,8 +130,6 @@ proc ComboBox::create { path args } {
     }
 
     ::bind $path  <ButtonPress-1> [list ComboBox::_unmapliste $path]
-    ::bind $entry <Key-Up>	  [list ComboBox::_unmapliste $path]
-    ::bind $entry <Key-Down>	  [list ComboBox::_mapliste $path]
     ::bind $entry <Control-Up>	  [list ComboBox::_modify_value $path previous]
     ::bind $entry <Control-Down>  [list ComboBox::_modify_value $path next]
     ::bind $entry <Control-Prior> [list ComboBox::_modify_value $path first]
@@ -731,3 +737,66 @@ proc ComboBox::_auto_complete { path key
     $path.e icursor $idx
     $path.e select range insert end
 }
+
+proc ComboBox::_auto_post { path key } {
+    if {[string equal $key "Escape"]} {
+        _unmapliste $path
+        return
+    }
+    if {[catch {$path.shell.listb curselection} x] || $x == ""} {
+        if {[string equal $key "Up"]} {
+            _unmapliste $path
+            return
+        }
+        set x -1
+    }
+    if {[string tolower $key] != $key && \
+            [string equal $key "Backspace"] != 0 && \
+            [string equal $key "Up"] != 0 && \
+            [string equal $key "Down"] != 0} {
+        return
+    }
+
+    # post the listbox
+    _create_popup $path
+    set width [Widget::cget $path -listboxwidth]
+    if {!$width} { set width [winfo width $path] }
+    BWidget::place $path.shell $width 0 below $path
+    wm deiconify $path.shell
+    BWidget::grab release $path
+    BWidget::focus release $path.shell.listb 1
+    focus -force $path.e
+
+    set values [Widget::cget $path -values]
+    switch -- $key {
+        Up {
+            if {[incr x -1] < 0} {
+                set x 0
+            } else {
+                Entry::configure $path.e -text [lindex $values $x]
+            }
+        }
+        Down {
+            if {[incr x] >= [llength $values]} {
+                set x [expr {[llength $values] - 1}]
+            } else {
+                Entry::configure $path.e -text [lindex $values $x]
+            }
+        }
+        default {
+            # auto-select within the listbox the item closest to the entry's value
+            set text [string map [list {[} {\[} {]} {\]}] [$path.e get]]
+            if {[string equal $text ""]} {
+                set x 0
+            } else {
+                set x [lsearch $values $text*]
+            }
+        }
+    }
+
+    if {$x >= 0} {
+        $path.shell.listb selection clear 0 end
+        $path.shell.listb selection set $x
+        $path.shell.listb see $x
+    }
+}



-- 
Jason Tang  /  ta...@jt...  /  http://www.jtang.org/~tang

Re: [Tcllib-devel] More file utilities ?

[Reinhard M. <ma...@tc...>]

Hi,

On Tue, 31 Jan 2006 at 08:29, Hemang Lavana wrote:

> [touch]
> Also, will it create the parent directory if it doesn't exist?
> I think it should.

I think the default behaviour should match unix touch, which throws an 
error if the parent directory doesn't exist, but we could have an 
option to tell our touch command to create the directory.

cu
	Reinhard

Re: [Tcllib-devel] More file utilities ?

[Reinhard M. <ma...@tc...>]

Hi,

On Tue, 31 Jan 2006 at 13:18, Neil Madden wrote:

> I'd vote for directly into the "fileutil" namespace.

me too. I see no need here to make the command names even longer by 
adding a level of sub-namespaces.

> Perhaps mapfile or filemap or even just map (i.e. [fileutil::map]) 
> as it is quite similar to [string map]? The copy version can be done 
> as an option: fileutil map -copy $outfile $infile key val ...

How about this signature?

fileutil::map {key value ...} infile ?outfile?

It would be a mixture of [string map] (regarding the mapping list) and 
[regsub] (regarding the optional "to" argument).


Off-topic remark: maybe even [string map] could be extended to allow 
an optional "out" argument, so

	set x [string map $map $y]

would become

	string map $map $x y

... and the return value of the command could be the number of 
replacements that have been done, as it is with [regsub]

cu
Reinhard

Re: [Tcllib-devel] More file utilities ?

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

Hi Andreas,

I would also vote for fileutils namespace. Suggestions for few proc
names are:

getfile  -> ::fileutil::read
putfile  -> ::fileutil::write
appendto -> ::fileutil::append

As others have mentioned, touch should not delete the file. Also, will
it create the parent directory if it doesn't exist? I think it should.

Hemang.

Andreas Kupries wrote:
> 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).
>
> Below are the commands collected so far. I would like to get opinions
> on whether these commands should really be put into Tcllib, and if
> yes, where.
>
> 	getfile PATH
>
> 		Returns contents of file. Assumes that file is text,
> 		and in system encoding.
>
> 		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.
>
> 	touch PATH
>
> 		Creates empty file at PATH. Deletes any pre-existing
> 		file in this location.
>
> 	appendto PATH DATA
>
> 		See putfile, but appends the data to existing
> 		content. Returns the location of the first character
> 		of the appended data in the file.
>
> 	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.
>
> 	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.
>
>
>   

Re: [Tcllib-devel] More file utilities ?

[Neil M. <ne...@cs...>]

Andreas Kupries wrote:
> 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'.

I'd vote for directly into the "fileutil" namespace.

> 	getfile PATH
> 
> 		Returns contents of file. Assumes that file is text,
> 		and in system encoding.
> 
> 		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.

Perhaps these can be extended to take options like -encoding 
-translation etc (some suitable subset of [chan configure] options)?

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

I'm with Mark G. Saye on this one -- if it's called "touch" it shouldn't 
delete a pre-existing file, but just update its atime/mtime.

> 
> 	appendto PATH DATA
> 
> 		See putfile, but appends the data to existing
> 		content. Returns the location of the first character
> 		of the appended data in the file.
> 
> 	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.

Again, perhaps [chan configure] options are relevant here?

> 
> 	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.

Perhaps mapfile or filemap or even just map (i.e. [fileutil::map]) as it 
is quite similar to [string map]? The copy version can be done as an 
option: fileutil map -copy $outfile $infile key val ...

-- Neil