Chris Muller uploaded a new version of Files to project The Inbox: http://source.squeak.org/inbox/Files-cmm.207.mcz
==================== Summary ====================
Name: Files-cmm.207 Author: cmm Time: 28 April 2024, 7:24:18.020282 pm UUID: 7f3afa72-a69e-48be-aae7-a50900bfd4a3 Ancestors: Files-ul.206
- Support #currentDirectoryNickname from FileDirectory class>>#on:. - Don't allow FileStream class>>#newFileNamed:do: and #forceNewFileNamed:do: to fail silently.
=============== Diff against Files-ul.206 ===============
Item was changed: ----- Method: FileDirectory class>>on: (in category 'instance creation') ----- on: pathString "Return a new file directory for the given path, of the appropriate FileDirectory subclass for the current OS platform."
| pathName | DirectoryClass ifNil: [self setDefaultDirectoryClass]. "If path ends with a delimiter (: or /) then remove it" pathName := pathString. (pathName at: pathName size ifAbsent: nil) = self pathNameDelimiter ifTrue: [pathName := pathName allButLast]. DirectoryClass parentDirectoryNickname ifNotNil: [:parentName| (pathName beginsWith: parentName) ifTrue: [pathName = parentName ifTrue: [^self default containingDirectory]. (pathName at: parentName size + 1 ifAbsent: nil) = self pathNameDelimiter ifTrue: [^self default containingDirectory on: (pathName allButFirst: parentName size + 1)]]]. + DirectoryClass currentDirectoryNickname ifNotNil: + [: currentName| + (pathName beginsWith: currentName) ifTrue: + [pathName = currentName ifTrue: + [^self default]. + (pathName at: currentName size + 1 ifAbsent: nil) = self pathNameDelimiter ifTrue: + [^self default on: (pathName allButFirst: currentName size + 1)]]]. + ^DirectoryClass new setPathName: pathName!
Item was changed: ----- Method: FileStream class>>forceNewFileNamed:do: (in category 'instance creation') ----- + forceNewFileNamed: fileName do: aBlock + "Create a file named fileName and value aBlock with a ReadWriteStream on its contents, which is closed automatically upon completion of aBlock. If the file identified by fileName already exists, it will be replaced. If the file can't be created for any reason, signal an error." + ^ (self forceNewFileNamed: fileName) + ifNil: [ self error: 'file not created' ] + ifNotNil: [ : fileStream | self detectFile: fileStream do: aBlock ]! - forceNewFileNamed: fileName do: aBlock - "Avi Bryant says, ''This idiom is quite common in other languages that make heavy use of closures (i.e. Lisp (with-file 'foo' (f) ...) and Ruby (File.open('foo'){|f|...})). It's time Squeak had it, too.'' - - Returns the result of aBlock." - - ^self detectFile: (self forceNewFileNamed: fileName) do: aBlock!
Item was changed: ----- Method: FileStream class>>newFileNamed:do: (in category 'instance creation') ----- + newFileNamed: fileName do: aBlock + "Create a file named fileName and value aBlock with a ReadWriteStream on its contents, which is closed automatically upon completion of aBlock. If the file identified by fileName already exists, signal an error. If the file can't be created for any reason, signal an error." + ^ (self newFileNamed: fileName) + ifNil: [ self error: 'file not created' ] + ifNotNil: [ : fileStream | self detectFile: fileStream do: aBlock ]! - newFileNamed: fileName do: aBlock - "Avi Bryant says, ''This idiom is quite common in other languages that make heavy use of closures (i.e. Lisp (with-file 'foo' (f) ...) and Ruby (File.open('foo'){|f|...})). It's time Squeak had it, too.'' - - Returns the result of aBlock." - - ^self detectFile: (self newFileNamed: fileName) do: aBlock!
On 2024-04-29T00:24:19+00:00, commits@source.squeak.org wrote:
Chris Muller uploaded a new version of Files to project The Inbox: http://source.squeak.org/inbox/Files-cmm.207.mcz
==================== Summary ====================
Name: Files-cmm.207 Author: cmm Time: 28 April 2024, 7:24:18.020282 pm UUID: 7f3afa72-a69e-48be-aae7-a50900bfd4a3 Ancestors: Files-ul.206
- Support #currentDirectoryNickname from FileDirectory class>>#on:.
It's surprising that this has already worked before, but this change surely brings it onto a more secure foundation. Looks good to me (from as far as I can tell). :-)
- Don't allow FileStream class>>#newFileNamed:do: and #forceNewFileNamed:do: to fail silently.
Oh yes, please, finally! :D But maybe patch the remaining *FileNamed:do:* methods in FileStream class as well.
=============== Diff against Files-ul.206 ===============
Item was changed: ----- Method: FileDirectory class>>on: (in category 'instance creation') ----- on: pathString "Return a new file directory for the given path, of the appropriate FileDirectory subclass for the current OS platform."
| pathName | DirectoryClass ifNil: [self setDefaultDirectoryClass]. "If path ends with a delimiter (: or /) then remove it" pathName := pathString. (pathName at: pathName size ifAbsent: nil) = self pathNameDelimiter ifTrue: [pathName := pathName allButLast]. DirectoryClass parentDirectoryNickname ifNotNil: [:parentName| (pathName beginsWith: parentName) ifTrue: [pathName = parentName ifTrue: [^self default containingDirectory]. (pathName at: parentName size + 1 ifAbsent: nil) = self pathNameDelimiter ifTrue: [^self default containingDirectory on: (pathName allButFirst: parentName size + 1)]]].
- DirectoryClass currentDirectoryNickname ifNotNil:
[: currentName|(pathName beginsWith: currentName) ifTrue:[pathName = currentName ifTrue:[^self default].(pathName at: currentName size + 1 ifAbsent: nil) = self pathNameDelimiter ifTrue:[^self default on: (pathName allButFirst: currentName size + 1)]]].- ^DirectoryClass new setPathName: pathName!
Item was changed: ----- Method: FileStream class>>forceNewFileNamed:do: (in category 'instance creation') -----
- forceNewFileNamed: fileName do: aBlock
- "Create a file named fileName and value aBlock with a ReadWriteStream on its contents, which is closed automatically upon completion of aBlock. If the file identified by fileName already exists, it will be replaced. If the file can't be created for any reason, signal an error."
- ^ (self forceNewFileNamed: fileName)
ifNil: [ self error: 'file not created' ]ifNotNil: [ : fileStream | self detectFile: fileStream do: aBlock ]!
- forceNewFileNamed: fileName do: aBlock
- "Avi Bryant says, ''This idiom is quite common in other languages that make heavy use of closures (i.e. Lisp (with-file 'foo' (f) ...) and Ruby (File.open('foo'){|f|...})). It's time Squeak had it, too.''
- Returns the result of aBlock."
- ^self detectFile: (self forceNewFileNamed: fileName) do: aBlock!
Item was changed: ----- Method: FileStream class>>newFileNamed:do: (in category 'instance creation') -----
- newFileNamed: fileName do: aBlock
- "Create a file named fileName and value aBlock with a ReadWriteStream on its contents, which is closed automatically upon completion of aBlock. If the file identified by fileName already exists, signal an error. If the file can't be created for any reason, signal an error."
- ^ (self newFileNamed: fileName)
ifNil: [ self error: 'file not created' ]ifNotNil: [ : fileStream | self detectFile: fileStream do: aBlock ]!
- newFileNamed: fileName do: aBlock
- "Avi Bryant says, ''This idiom is quite common in other languages that make heavy use of closures (i.e. Lisp (with-file 'foo' (f) ...) and Ruby (File.open('foo'){|f|...})). It's time Squeak had it, too.''
- Returns the result of aBlock."
- ^self detectFile: (self newFileNamed: fileName) do: aBlock!
Best, Christoph
--- Sent from Squeak Inbox Talk
Hi Christoph,
Thanks for the review.
- Support #currentDirectoryNickname from FileDirectory class>>#on:.
It's surprising that this has already worked before,
'.' alone worked, but not './mySubDir'.
- Don't allow FileStream class>>#newFileNamed:do: and
#forceNewFileNamed:do: to fail silently.
Oh yes, please, finally! :D But maybe patch the remaining *FileNamed:do:* methods in FileStream class as well.
I think I agree, however, "fileNamed:do:" could also be interpreted as, "For the file named [arg1], if it exists, do this block [arg2]." I also worried about compatibility on that one.
Whereas, newFileNamed explicitly intends to create a "new" file.
Any other opinions on #fileNamed:do:?
- Chris
On 2024-05-06, at 1:58 PM, Chris Muller asqueaker@gmail.com wrote:
I think I agree, however, "fileNamed:do:" could also be interpreted as, "For the file named [arg1], if it exists, do this block [arg2]." I also worried about compatibility on that one.
Whereas, newFileNamed explicitly intends to create a "new" file.
Any other opinions on #fileNamed:do:?
One might consider slightly more explicit names -
withExistingFileNamed:do: createNewFileNamed:andDo: (possibly more assertively) forceNewFileNamed:andDo:
And maybe similar for directories.
You could also imagine #withExistingFileNamed:do:ifMissing: but then you'd start to feel like wanting to add ifBadFileName: and ifNoPermissions: etc. Wrapping it in an error handler clearly works, though it's amazing how often people don't really have any idea what ought to be done when there is an error.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- VENI, VIDI, VISA - I came, I saw, I bought
Just for reference, if you have OSProcess/CommandShell loaded you may want to look at classes ShellSyntax and ShellSyntaxTestCase, especially method category 'path name expansion'.
The #currentDirectoryNickname and #parentDirectoryNickname methods are useful convenience methods, but they are really based on Unix shell syntax conventions so we would not want too much of this logic leaking into the base image.
$0.02,
Dave
On 2024-05-06 20:58, Chris Muller wrote:
Hi Christoph,
Thanks for the review.
- Support #currentDirectoryNickname from FileDirectory class>>#on:.
It's surprising that this has already worked before,
'.' alone worked, but not './mySubDir'.
- Don't allow FileStream class>>#newFileNamed:do: and
#forceNewFileNamed:do: to fail silently.
Oh yes, please, finally! :D But maybe patch the remaining *FileNamed:do:* methods in FileStream class as well.
I think I agree, however, "fileNamed:do:" could also be interpreted as, "For the file named [arg1], if it exists, do this block [arg2]." I also worried about compatibility on that one.
Whereas, newFileNamed explicitly intends to create a "new" file.
Any other opinions on #fileNamed:do:?
- Chris
On Mon, May 6, 2024 at 5:29 PM lewis@mail.msen.com wrote:
Just for reference, if you have OSProcess/CommandShell loaded you may want to look at classes ShellSyntax and ShellSyntaxTestCase, especially method category 'path name expansion'.
The #currentDirectoryNickname and #parentDirectoryNickname methods are useful convenience methods, but they are really based on Unix shell syntax conventions so we would not want too much of this logic leaking into the base image.
".." means the same thing in the win32 filesystem as it does in Unix. I seriously doubt any filesystem in which shells are used doesn't have a nickname for the parent directory. The image framework allows a different nickname to be used. I don't see the harm myself.
This kind of thing feels to me like "asking forgiveness" is easier than not using it, in that we can fix usage later when we encounter a filesystem t6hat breaks the mould. That's better than struggling to do without common and useful facilities.
$0.02,
Dave
On 2024-05-06 20:58, Chris Muller wrote:
Hi Christoph,
Thanks for the review.
- Support #currentDirectoryNickname from FileDirectory class>>#on:.
It's surprising that this has already worked before,
'.' alone worked, but not './mySubDir'.
- Don't allow FileStream class>>#newFileNamed:do: and
#forceNewFileNamed:do: to fail silently.
Oh yes, please, finally! :D But maybe patch the remaining *FileNamed:do:* methods in FileStream class as well.
I think I agree, however, "fileNamed:do:" could also be interpreted as, "For the file named [arg1], if it exists, do this block [arg2]." I also worried about compatibility on that one.
Whereas, newFileNamed explicitly intends to create a "new" file.
Any other opinions on #fileNamed:do:?
- Chris
".." means the same thing in the win32 filesystem as it does in Unix. I seriously doubt any filesystem in which shells are used doesn't have a nickname for the parent directory. Maybe flat file systems such as AWS S3 could be an assumption to this rule? ________________________________ Von: Eliot Miranda eliot.miranda@gmail.com Gesendet: Mittwoch, 8. Mai 2024 01:18 Uhr An: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Cc: ma.chris.m@gmail.com ma.chris.m@gmail.com Betreff: [squeak-dev] Re: The Inbox: Files-cmm.207.mcz
On Mon, May 6, 2024 at 5:29 PM <lewis@mail.msen.commailto:lewis@mail.msen.com> wrote:
Just for reference, if you have OSProcess/CommandShell loaded you may want to look at classes ShellSyntax and ShellSyntaxTestCase, especially method category 'path name expansion'.
The #currentDirectoryNickname and #parentDirectoryNickname methods are useful convenience methods, but they are really based on Unix shell syntax conventions so we would not want too much of this logic leaking into the base image.
".." means the same thing in the win32 filesystem as it does in Unix. I seriously doubt any filesystem in which shells are used doesn't have a nickname for the parent directory. The image framework allows a different nickname to be used. I don't see the harm myself.
This kind of thing feels to me like "asking forgiveness" is easier than not using it, in that we can fix usage later when we encounter a filesystem t6hat breaks the mould. That's better than struggling to do without common and useful facilities.
$0.02,
Dave
On 2024-05-06 20:58, Chris Muller wrote:
Hi Christoph,
Thanks for the review.
- Support #currentDirectoryNickname from FileDirectory class>>#on:.
It's surprising that this has already worked before,
'.' alone worked, but not './mySubDir'.
- Don't allow FileStream class>>#newFileNamed:do: and #forceNewFileNamed:do: to fail silently.
Oh yes, please, finally! :D But maybe patch the remaining *FileNamed:do:* methods in FileStream class as well.
I think I agree, however, "fileNamed:do:" could also be interpreted as, "For the file named [arg1], if it exists, do this block [arg2]." I also worried about compatibility on that one.
Whereas, newFileNamed explicitly intends to create a "new" file.
Any other opinions on #fileNamed:do:?
- Chris
-- _,,,^..^,,,_ best, Eliot
Hi Eliot,
I'm sorry if my tone was critical, I did not mean it that way. As I said, these are useful convenience methods.
Dave
On 2024-05-07 23:18, Eliot Miranda wrote:
On Mon, May 6, 2024 at 5:29 PM lewis@mail.msen.com wrote:
Just for reference, if you have OSProcess/CommandShell loaded you may want to look at classes ShellSyntax and ShellSyntaxTestCase, especially method category 'path name expansion'.
The #currentDirectoryNickname and #parentDirectoryNickname methods are useful convenience methods, but they are really based on Unix shell syntax conventions so we would not want too much of this logic leaking into the base image.
".." means the same thing in the win32 filesystem as it does in Unix. I seriously doubt any filesystem in which shells are used doesn't have a nickname for the parent directory. The image framework allows a different nickname to be used. I don't see the harm myself.
This kind of thing feels to me like "asking forgiveness" is easier than not using it, in that we can fix usage later when we encounter a filesystem t6hat breaks the mould. That's better than struggling to do without common and useful facilities.
$0.02,
Dave
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
christoph.thiede＠student.hpi.uni-potsdam.de -
commits＠source.squeak.org -
Eliot Miranda -
lewis＠mail.msen.com -
Thiede, Christoph
-
Tim Rowledge