Menu
▾
▴
tcllib-devel
|
From: Andreas K. <aku...@sh...> - 2006-01-31 05:31:19
|
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.
--
So long,
Andreas Kupries <aku...@sh...>
<http://www.purl.org/NET/akupries/>
Developer @ <http://www.activestate.com/>
-------------------------------------------------------------------------------
|
|
From: Arjen M. <arj...@wl...> - 2006-01-31 07:47:06
|
Andreas Kupries wrote: > Subject: [Tcllib-devel] More file utilities ? > Date: Mon, 30 Jan 2006 21:27:08 -0800 > From: Andreas Kupries <aku...@sh...> > To: Tcllib Development <tcl...@li...> > > 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) Regards, Arjen |
|
From: Andreas K. <and...@Ac...> - 2006-01-31 17:18:59
|
> > 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 |
|
From: Jeff H. <je...@Ac...> - 2006-01-31 17:25:47
|
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 |
|
From: Mark G. S. <mar...@ya...> - 2006-01-31 08:16:30
|
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'. > > > 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 ? -- Mark G. Saye markgsaye @ yahoo.com |
|
From: Jeff H. <je...@Ac...> - 2006-01-31 16:12:27
|
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 |
|
From: Andreas K. <and...@Ac...> - 2006-01-31 17:20:58
|
> > 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 |
|
From: Neil M. <ne...@cs...> - 2006-01-31 13:17:42
|
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 |
|
From: Reinhard M. <ma...@tc...> - 2006-01-31 13:31:35
|
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
|
|
From: Andreas K. <and...@Ac...> - 2006-01-31 17:31:14
|
> 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
|
|
From: Reinhard M. <ma...@tc...> - 2006-01-31 17:47:19
|
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 |
|
From: Andreas K. <and...@Ac...> - 2006-01-31 18:00:37
|
> 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 |
|
From: Reinhard M. <ma...@tc...> - 2006-01-31 18:24:42
|
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 |
|
From: Andreas K. <and...@Ac...> - 2006-01-31 18:38:04
|
> > > 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 |
|
From: <dg...@ni...> - 2006-01-31 21:15:36
|
Quoting Reinhard Max <ma...@tc...>: > Wasn't it the default recommendation for library writers to use > qualified names instead of importing everything? There are advocates for that recommendation. There are also dissenters, like myself. This isn't the thread to dissect the pros/cons, but wanted to snuff the presumption that there's a settled "default" recommendation. DGP |
|
From: Andreas K. <and...@Ac...> - 2006-01-31 17:26:05
|
> > 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 |
|
From: Hemang L. <hl...@ci...> - 2006-01-31 13:30:22
|
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.
>
>
>
|
|
From: Reinhard M. <ma...@tc...> - 2006-01-31 13:39:26
|
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 |
|
From: Andreas K. <and...@Ac...> - 2006-01-31 17:27:07
|
> 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 |
|
From: <Lar...@re...> - 2006-01-31 15:40:59
|
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=
|
|
From: Andreas K. <and...@Ac...> - 2006-01-31 17:43:24
|
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
|
|
From: <dg...@ni...> - 2006-01-31 21:20:12
|
Quoting Andreas Kupries <and...@Ac...>: > 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. Citing [::tcltest::makeFile] is a negative recommendation, in my opinion. That command is about 80% a mistake. Unless you're providing some really compelling syntactic sugar, I don't see the point of a package providing commands that duplicate commands that are already built-in to Tcl. DGP |
|
From: Andreas K. <aku...@sh...> - 2006-02-02 07:16:05
|
Here is an updated proposal.
Overview:
* get_file/readFile is gone, replaced by the existing 'cat'
command, albeit extended (encodings, etc.).
* The 'touch' command which confused everyone (also called
'clear'), is gone as well.
* The basic modifications of a file in place (insertion,
removal, replacement of segments) are represented by their own
commands (keeping memory usage down), everything else has to
be expressed in terms of the 'updateInPlace' command Joe
proposed after looking at the old 'hack*' commands.
Now for the descriptions ...
=================================================
Basic descriptions for a set of commands operating on whole files.
The recognized options are generally
-encoding ENC
-translation TRA
-eofchar ECH
--
where "--" forces the recognition of a file, even if its name start
with a dash. None of the options are required. Unspecified settings
use the system defaults of the channel.
=================================================
::fileutil::cat (?options? file)+
Read all specified files, using the given options, and return
a string containing the concatenated contents.
Note: option settings persist between file names, i.e. when
doing
cat -encoding binary fileA fileB
fileB will be read using the binary encoding as well.
The specified paths have to exist, have to refer to files, and
have to be readable.
::fileutil::writeFile ?options? file data
Writes the data into the file, creating it if needed.
If the specified path exists it has to refer to a writable
file.
::fileutil::appendToFile ?options? file data
Appends the data to the file.
The specified path has to refer to an existing readable and
writable file.
::fileutil::insertIntoFile ?options? file at data
Insert the data into the file, at the offset.
The specified path has to refer to an existing readable and
writable file.
::fileutil::removeFromFile ?options? file at n
Removes n characters from the file, starting at the given
offset. Characters are counted as per the active encoding.
The specified path has to refer to an existing readable and
writable file.
::fileutil::replaceInFile ?options? file at n data
A combination of 'removeFromFile' and
'insertIntoFile'. Removes n characters from the file, starting
at the given offset, and replaces them with the given data.
The specified path has to refer to an existing readable and
writable file.
Semantics:
removeFromFile path at n
insertIntoFile path at data
::fileutil::updateInPlace ?options? file cmd
Reads the contents of the file and passes it as an additional
argument to the cmd (prefix). Overwrites the original file
with the return value of the command. If the command raises an
error, the original file is not modified.
The specified path has to refer to an existing readable and
writable file.
The last three operations could be expressed in terms of
updateInPlace. Their transforms are however so simple that a
direct implementation is possible without loading the whole
file into memory.
=================================================
--
So long,
Andreas Kupries <aku...@sh...>
<http://www.purl.org/NET/akupries/>
Developer @ <http://www.activestate.com/>
-------------------------------------------------------------------------------
|
|
From: Andreas K. <aku...@sh...> - 2006-02-10 03:48:23
|
> Here is an updated proposal. Having heard nothing anymore I implemented this and just committed it, including updated testsuite and documentation. -- So long, Andreas Kupries <aku...@sh...> <http://www.purl.org/NET/akupries/> Developer @ <http://www.activestate.com/> ------------------------------------------------------------------------------- |
|
From: Andreas K. <and...@Ac...> - 2006-01-31 17:14:53
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X