r28017 - in docs/Perl6/Spec: . S32-setting-library
Author: wayland
Date: 2009-08-18 09:24:07 +0200 (Tue, 18 Aug 2009)
New Revision: 28017
Modified:
docs/Perl6/Spec/S02-bits.pod
docs/Perl6/Spec/S16-io.pod
docs/Perl6/Spec/S28-special-names.pod
docs/Perl6/Spec/S32-setting-library/IO.pod
Log:
[S02] Changed :io to :p and :path
[S16] Documented p{/path/to/file}
[S28] Made $*CWD have type Path instead of Str
[S32/IO] Many changes, including:
* Changed IO::FSNode into Path
* Merged most of IO::DirectoryNode and all of IO::LinkNode into Path (but still
need to
merge IO::FileNode)
* Moved remnants of IO::DirectoryNode to IO::Directory
It's not finished yet, but I thought I'd commit anyway. I'll keep working on
it.
Modified: docs/Perl6/Spec/S02-bits.pod
===
--- docs/Perl6/Spec/S02-bits.pod2009-08-17 21:09:32 UTC (rev 28016)
+++ docs/Perl6/Spec/S02-bits.pod2009-08-18 07:24:07 UTC (rev 28017)
@@ -2834,7 +2834,7 @@
:subst Parse as substitution
:trans Parse as transliteration
:code Quasiquoting
-:io Return an IO::FSNode
+:p :path Return a Path object
You may omit the first colon by joining an initial CQ, Cq, or Cqq with
a single short form adverb, which produces forms like:
Modified: docs/Perl6/Spec/S16-io.pod
===
--- docs/Perl6/Spec/S16-io.pod 2009-08-17 21:09:32 UTC (rev 28016)
+++ docs/Perl6/Spec/S16-io.pod 2009-08-18 07:24:07 UTC (rev 28017)
@@ -82,17 +82,55 @@
The use of filenames requires a special quoting syntax. It works as follows:
-q:io{/path/to/file}
+p{/path/to/file}
+q:p{/path/to/file}
+Both of the above result in the same thing.
+
The quote characters can be any of the usual ones, although / is probably a
bad choice
for filenames.
-The code shown above returns an IO::FSNode object (or a descendant thereof).
+The code shown above returns a Path object (or a descendant thereof).
Naturally you can also ask for interpolation in filenames:
-qq:io{$directory/$file}
+p:qq{$directory/$file}
+qq:p{$directory/$file}
+There are a number of special adverbs that can be applied to the file quoting
+operator. Most of these are filesystem-specific. They confine what can be
+included in a filename.
+
+=head3 Default constraints
+
+The default p{} only allows / as separator and does not allow path elements
+to contain
+characters that won't work on modern Windows and Unix like \ / ? % * : | ,
+etc. The reason for this is that portable paths are the default. If
+platform/filesystem specific behavior is really needed it should be shown in
+the code by applying different sets of constraints (see below).
+
+=head3 Windows-style constraints
+
+We allow windows style paths so converting and maintaining code on this
+platform is not a pain.
+
+my Path $path = p:win{C:\Program Files\MS Access\file.file};
+
+Note that this specifically excludes the backslash quoting usually used with
+q{}.
+
+=head3 Unix-style constraints
+
+For Unix specific behavior we have a p:unix{} literal. Here the only
+limits are what is defined by the locale and the filesystem type. So we won't
+be able to write full Unicode if locale is set to Latin1.
+
+my Path $path = p:unix{/usr/src/bla/myfile?:%.file};
+
+And for cases where this is a problem p:bin{} can be used as no checking is
+done here, other than assuming that / is the separator.
+
=head1 Name Services
=head2 User role
Modified: docs/Perl6/Spec/S28-special-names.pod
===
--- docs/Perl6/Spec/S28-special-names.pod 2009-08-17 21:09:32 UTC (rev
28016)
+++ docs/Perl6/Spec/S28-special-names.pod 2009-08-18 07:24:07 UTC (rev
28017)
@@ -68,7 +68,7 @@
Variable Spec Type Description
---
- @_ # ???
+ @_ # ??? (FIX)
$!S04# Current Exception object
$/S05 Match# Last match
$0, $1, $2S05 Str # First captured value from match: $/[0]
@@ -81,7 +81,7 @@
$?CLASS S02 Class# current class
@=COMMENT(S26) # All the comment blocks in the file
%?CONFIGHash of XXX # configuration hash XXX What does this
do?
- $*CWD Str # current working directory
+ $*CWD Path # current working directory
$=DATA (S26) IO # data block handle (=begin DATA ...
=end)
@=DATA (S26) Array# Same as above, but array
%?DEEPMAGIC S13 Hash of XXX # Controls the mappings of magical names
to sub definitions
Modified: docs/Perl6/Spec/S32-setting-library/IO.pod
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
On Tue, Aug 18, 2009 at 09:24:08AM +0200, pugs-comm...@feather.perl6.nl wrote:
+=head3 Default constraints
+
+The default p{} only allows / as separator and does not allow path
elements
+to contain
+characters that won't work on modern Windows and Unix like \ / ? % * : |
,
+etc. The reason for this is that portable paths are the default. If
+platform/filesystem specific behavior is really needed it should be shown in
+the code by applying different sets of constraints (see below).
Perl 5 runs on (at least) VMS and VOS too. So, if Perl 6 is to adopt a policy
of enforced portable filenames by default, it should (at least) also exclude
- as the first character, and forbid more than one . in a filename.
(Also, I suspect, ; and . are illegal in directory names.
And on VMS catfile() and catdir() *are* distinct operations, so it's important
to know if the right-most argument is a file or a directory)
Nicholas Clark
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
2009/8/18 pugs-comm...@feather.perl6.nl: Author: wayland Date: 2009-08-18 09:24:07 +0200 (Tue, 18 Aug 2009) New Revision: 28017 +=item chdir FILENAME +Xchdir Xcd + +=item chdir + +Gone, just set $*CWD (which throws an exception if it fails). + chdir provides functionality that would be quite convoluted to mimic through manually setting $*CWD, such as changing to a relative directory. Unless there are ways to do it that I'm missing, this doesn't seem like a good idea. -- Carlin
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
On Tue, Aug 18, 2009 at 10:01 AM, Nicholas Clarkn...@ccl4.org wrote:
On Tue, Aug 18, 2009 at 09:24:08AM +0200, pugs-comm...@feather.perl6.nl wrote:
+=head3 Default constraints
+
+The default p{} only allows / as separator and does not allow path
elements
+to contain
+characters that won't work on modern Windows and Unix like \ / ? % * : |
,
+etc. The reason for this is that portable paths are the default. If
+platform/filesystem specific behavior is really needed it should be shown in
+the code by applying different sets of constraints (see below).
Perl 5 runs on (at least) VMS and VOS too. So, if Perl 6 is to adopt a policy
of enforced portable filenames by default, it should (at least) also exclude
- as the first character, and forbid more than one . in a filename.
And, as I mentioned in an earlier post during the discussion, the
restrictions for Windows are numerous:
http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx
Enforcing truly portable filenames is unrealistic, I think, but
having a POSIX-checking default is a good thing.
--
Jan
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
On Tue, Aug 18, 2009 at 10:36:45AM +0200, Jan Ingvoldstad wrote:
On Tue, Aug 18, 2009 at 10:01 AM, Nicholas Clarkn...@ccl4.org wrote:
On Tue, Aug 18, 2009 at 09:24:08AM +0200, pugs-comm...@feather.perl6.nl
wrote:
+=head3 Default constraints
+
+The default p{} only allows / as separator and does not allow path
elements
+to contain
+characters that won't work on modern Windows and Unix like \ / ? % * : |
,
+etc. The reason for this is that portable paths are the default. If
+platform/filesystem specific behavior is really needed it should be shown
in
+the code by applying different sets of constraints (see below).
Perl 5 runs on (at least) VMS and VOS too. So, if Perl 6 is to adopt a
policy
of enforced portable filenames by default, it should (at least) also exclude
- as the first character, and forbid more than one . in a filename.
And, as I mentioned in an earlier post during the discussion, the
restrictions for Windows are numerous:
http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx
Oh gosh yes. I forgot. AUX.TXT
And all the the other CP/M device file names, with our without extensions...
[And of course, IIRC, DOS filenames can't be more than 64 characters. Which
means that your code thinks that it knows what it's doing by stripping of
the drive letter and allowing 62 in the rest of the pathname. Except that
I remember university servers with drives UX: and UY:, which always made me
wonder if there was a buffer overflow waiting to happen...]
Enforcing truly portable filenames is unrealistic, I think, but
having a POSIX-checking default is a good thing.
What does POSIX enforce? ASCII NUL terminated, multiple adjacent / characters
fold to 1, except at the start, where // is special, but /// etc aren't?
And anything else goes?
Nicholas Clark
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
On 2009-Aug-18, at 2:29 am, Carlin Bingham wrote: chdir provides functionality that would be quite convoluted to mimic through manually setting $*CWD, such as changing to a relative directory. Maybe setting $*CWD just calls chdir() under the hood? Same implementation, brand new shiny Perl-style interface! -David
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
On Tue, Aug 18, 2009 at 10:58 AM, Nicholas Clarkn...@ccl4.org wrote: Oh gosh yes. I forgot. AUX.TXT And all the the other CP/M device file names, with our without extensions... [And of course, IIRC, DOS filenames can't be more than 64 characters. Which means that your code thinks that it knows what it's doing by stripping of the drive letter and allowing 62 in the rest of the pathname. Except that I remember university servers with drives UX: and UY:, which always made me wonder if there was a buffer overflow waiting to happen...] Yes, lovely, isn't it? What does POSIX enforce? ASCII NUL terminated, multiple adjacent / characters fold to 1, except at the start, where // is special, but /// etc aren't? And anything else goes? POSIX doesn't enforce much. I used our friendly do-no-evil empire, and found this: http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html#standards And particularly from «2.2. Standards permit the exclusion of bad filenames»: «I then examined the Portable Filename Character Set, defined in 3.276 (“Portable Filename Character Set”); this turns out to be just A-Z, a-z, 0-9, period, underscore, and hyphen (aka the dash character). So it’s perfectly okay for a POSIX system to reject a non-portable filename due to it having “odd” characters or a leading hyphen.» -- Jan
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
On Tue, Aug 18, 2009 at 11:04 AM, David Greendavid.gr...@telus.net wrote: On 2009-Aug-18, at 2:29 am, Carlin Bingham wrote: chdir provides functionality that would be quite convoluted to mimic through manually setting $*CWD, such as changing to a relative directory. Maybe setting $*CWD just calls chdir() under the hood? Same implementation, brand new shiny Perl-style interface! It may seem cool, but I don't like secondary effects like that. They break the principle of least surprise. -- Jan
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
On Tue, 18 Aug 2009, David Green wrote: On 2009-Aug-18, at 2:29 am, Carlin Bingham wrote: chdir provides functionality that would be quite convoluted to mimic through manually setting $*CWD, such as changing to a relative directory. Maybe setting $*CWD just calls chdir() under the hood? Same implementation, brand new shiny Perl-style interface! That was my intent, but we had some discussions on IRC about the whys and wherefores, and it will return as soon as I do my next commit (hopefully sometime within the next 4-5 hours). Unless you can think of a good way to do relative paths. :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
r28018 - in docs/Perl6/Spec: . S32-setting-library
Author: wayland
Date: 2009-08-18 11:47:04 +0200 (Tue, 18 Aug 2009)
New Revision: 28018
Modified:
docs/Perl6/Spec/S02-bits.pod
docs/Perl6/Spec/S32-setting-library/IO.pod
Log:
[S32/IO] A few changes, including:
* Revived .chdir() due to popular demand
* IO::FileNode merged into Path
Modified: docs/Perl6/Spec/S02-bits.pod
===
--- docs/Perl6/Spec/S02-bits.pod2009-08-18 07:24:07 UTC (rev 28017)
+++ docs/Perl6/Spec/S02-bits.pod2009-08-18 09:47:04 UTC (rev 28018)
@@ -2834,7 +2834,7 @@
:subst Parse as substitution
:trans Parse as transliteration
:code Quasiquoting
-:p :path Return a Path object
+:p :path Return a Path object (see S16 for more options)
You may omit the first colon by joining an initial CQ, Cq, or Cqq with
a single short form adverb, which produces forms like:
Modified: docs/Perl6/Spec/S32-setting-library/IO.pod
===
--- docs/Perl6/Spec/S32-setting-library/IO.pod 2009-08-18 07:24:07 UTC (rev
28017)
+++ docs/Perl6/Spec/S32-setting-library/IO.pod 2009-08-18 09:47:04 UTC (rev
28018)
@@ -653,14 +653,23 @@
=over 4
-=item glob
+=item chdir FILENAME
+Xchdir Xcd
-Returns CPath objects.
+=item chdir
+Changes the current working directory to the one specified by FILENAME.
+If it succeeds it returns true, otherwise it returns CFailure and
+sets C$! (errno).
+
=item find
Returns CPath objects.
+=item glob
+
+Returns CPath objects.
+
=item rename
=back
@@ -674,7 +683,7 @@
role Path {
has Str $.Type;
has Array of Str @.Elements;
-has Array of IO::FSNodeACL @.ACLs;
+has Array of IO::ACL @.ACLs;
has Hash of %.times;
...
}
@@ -686,7 +695,8 @@
CAccess (and maybe others on other operating systems), and the values are
all CTemporal::Instant objects.
-C$.Type can be CFile, CDirectory, or CLink.
+C$.Type can be CFile, CDirectory, CLink, or COther. See
+C.create() method documentation for how it is set.
=head3 Methods
@@ -704,7 +714,7 @@
Array of Str @:PathElements,
Array of Str $:Constraints,
-Str $:Type,
+Str $:Protocol,
Str $:Target,
Str $:LinkType,
@@ -715,9 +725,19 @@
$:Constraints determines whether the $:Path and $:Target strings should be
assumed to be Unix-style, Windows-style, or something else.
-$:Type defaults to File, unless the $:Target parameter is passed, in which
-case it is assumed to be Link.
+The Path.Type attribute is initialised as follows:
+ValueCondition
+==
+Directory$:Path ends in a separator (ie. /)
+Link $:Target is specified
+Other$:Protocol is specified
+UndefinedAll other cases
+
+If the $.Type attribute is read, but is still undefined, then an attempt is
+made to determine what its type should be from the filesystem. If no
+answers are found using this method, then it defaults to File.
+
The CTarget and CLinkType options are only relevant for links that have
not been created yet, or are to be overwritten; in all other cases,
they will be determined from the filesystem. If Target is not specified,
@@ -795,6 +815,68 @@
throws an error unless the CRecursive option is specified. It returns the
number of nodes deleted, and may throw an exception.
+=item lines
+
+method lines ($handle:
+Any $limit = *,
+Bool $:bin = False,
+Str $:enc = Unicode,
+Any $:nl = \n,
+Bool $:chomp = True,
+-- List
+) is export
+
+multi lines (Str $filename,
+Any $limit = *,
+Bool $:bin = False,
+Str $:enc = Unicode,
+Any $:nl = \n,
+Bool $:chomp = True,
+-- List
+)
+
+Returns some or all the lines of a file or entries in a directory
+as a CList regardless of context.
+See also Cslurp. Note that lists are lazy by default, but you
+can always ask for Ceager lines. Note that the limit semantics cannot be
+duplicated by subscripting, since
+
+$fh.lines[^5]
+
+reads all the lines before the subscript gives you the first five,
+whereas
+
+$fh.lines(5)
+
+reads only five lines from the handle. Note that
+
+$fh.lines(1)
+
+is equivalent to
+
+$fh.get
+
+If fewer lines are available than the limit, it is not an error;
+you just get the number of lines available.
+
+=item slurp
+
+method slurp ($handle:
+Bool $:bin = False,
+Str $:enc = Unicode,
+-- Str|Buf
+) is export
+multi slurp (Str $filename,
+Bool $:bin = False,
+Str $:enc = Unicode,
+-- Str|Buf
+)
+
+Slurps the entire file into a CStr (or CBuf if C:bin) regardless of
context.
+(See also Clines.)
+
+In the case of a directory, it uses \n to
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
On Tue, Aug 18, 2009 at 11:04 AM, David Greendavid.gr...@telus.net wrote:
On 2009-Aug-18, at 2:29 am, Carlin Bingham wrote:
chdir provides functionality that would be quite convoluted to mimic
through manually setting $*CWD, such as changing to a relative
directory.
Maybe setting $*CWD just calls chdir() under the hood? Same implementation,
brand new shiny Perl-style interface!
If $*CWD is really a Path object and not a Str, then it should be easy
to use mutator methods to change to a relative directory and do other
chdir()ish things. Say, concatenation works in terms of path
components, for instance:
$*CWD ~= $subdir; # chdir($subdir)
With a method for getting the parent:
given $*CWD { $_ = $_.up ~ $sibling } # chdir(../$sibling)
and so on. My favorite kshism is cd old new which does a
search/replace on the current working directory; the bash equivalent
cd ${PWD/old/new} which is not quite as handy. $*CWD could make
that simple, too.
--
Mark J. Reed markjr...@gmail.com
r28019 - in docs/Perl6/Spec: . S32-setting-library
Author: wayland
Date: 2009-08-18 12:16:37 +0200 (Tue, 18 Aug 2009)
New Revision: 28019
Modified:
docs/Perl6/Spec/S16-io.pod
docs/Perl6/Spec/S32-setting-library/IO.pod
Log:
S32/IO: Mention that Path can be used as an array of path elements
S16: Restrict filenames to POSIX
Modified: docs/Perl6/Spec/S16-io.pod
===
--- docs/Perl6/Spec/S16-io.pod 2009-08-18 09:47:04 UTC (rev 28018)
+++ docs/Perl6/Spec/S16-io.pod 2009-08-18 10:16:37 UTC (rev 28019)
@@ -103,16 +103,21 @@
=head3 Default constraints
-The default p{} only allows / as separator and does not allow path elements
-to contain
-characters that won't work on modern Windows and Unix like \ / ? % * : | ,
-etc. The reason for this is that portable paths are the default. If
-platform/filesystem specific behavior is really needed it should be shown in
+The default paths are portable paths. These are POSIX-compatible (see
+POSIX.1-2008 sections4.7 and 3.276). If
+platform/filesystem specific behavior is needed it should be shown in
the code by applying different sets of constraints (see below).
+The default constraints are to only allow / as separator and only allows
+POSIX filenames. That means A-Z, a-z, 0-9, period, underscore, and
+hyphen. Additionally, hyphen may not be the first character in the path.
+
+Any path that starts with a / is considered an absolute path, otherwise
+the path is considered relative.
+
=head3 Windows-style constraints
-We allow windows style paths so converting and maintaining code on this
+We allow Windows style paths so converting and maintaining code on this
platform is not a pain.
my Path $path = p:win{C:\Program Files\MS Access\file.file};
@@ -131,6 +136,11 @@
And for cases where this is a problem p:bin{} can be used as no checking is
done here, other than assuming that / is the separator.
+=head3 Other constraints
+
+It is expected that other sets of constraints, such as VMS, DOS, and old-style
+Mac will be provided by modules.
+
=head1 Name Services
=head2 User role
Modified: docs/Perl6/Spec/S32-setting-library/IO.pod
===
--- docs/Perl6/Spec/S32-setting-library/IO.pod 2009-08-18 09:47:04 UTC (rev
28018)
+++ docs/Perl6/Spec/S32-setting-library/IO.pod 2009-08-18 10:16:37 UTC (rev
28019)
@@ -680,7 +680,7 @@
are usually created with the p{/path/to/file} syntax. It could be a directory,
file, link, or something else OS-specific.
-role Path {
+role Path does Str does Array {
has Str $.Type;
has Array of Str @.Elements;
has Array of IO::ACL @.ACLs;
@@ -698,6 +698,10 @@
C$.Type can be CFile, CDirectory, CLink, or COther. See
C.create() method documentation for how it is set.
+When used as a Str, it allows some operations, so that it can be concatenated
+easily with other strings. When used as an Array, it acts as an array of
+path elements.
+
=head3 Methods
=over 4
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
On Tue, 18 Aug 2009, Mark J. Reed wrote:
On Tue, Aug 18, 2009 at 11:04 AM, David Greendavid.gr...@telus.net wrote:
On 2009-Aug-18, at 2:29 am, Carlin Bingham wrote:
chdir provides functionality that would be quite convoluted to mimic
through manually setting $*CWD, such as changing to a relative
directory.
Maybe setting $*CWD just calls chdir() under the hood? Same implementation,
brand new shiny Perl-style interface!
If $*CWD is really a Path object and not a Str, then it should be easy
to use mutator methods to change to a relative directory and do other
chdir()ish things. Say, concatenation works in terms of path
components, for instance:
$*CWD ~= $subdir; # chdir($subdir)
With a method for getting the parent:
given $*CWD { $_ = $_.up ~ $sibling } # chdir(../$sibling)
and so on. My favorite kshism is cd old new which does a
search/replace on the current working directory; the bash equivalent
cd ${PWD/old/new} which is not quite as handy. $*CWD could make
that simple, too.
It's not in the revised spec, but I think that, even though
we've revived chdir, we should still have it so that changing $*CWD will do a
chdir under the hood.
My intent is that Path should be able to act as a string, at least to
a certain extent, and should also be able to act as an array of Str. So
Mark's second example could be done as:
pop $*CWD; push $*CWD $sibling
HTH,
-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am |
-
BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-
-END GEEK CODE BLOCK-
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
Perl 5 runs on (at least) VMS and VOS too. So, if Perl 6 is to adopt a policy of enforced portable filenames by default, it should (at least) also exclude - as the first character, and forbid more than one . in a filename. And, as I mentioned in an earlier post during the discussion, the restrictions for Windows are numerous: http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx Enforcing truly portable filenames is unrealistic, I think, but having a POSIX-checking default is a good thing. My idea with portable by default was only portability for modern Unix and modern Windows. So DOS and VMS limitations would not apply. The problem of enforcing truly portable filenames is that the files names get too restrictive and for most applications targeting 98% of systems out there would be enough. With modern Unix/Windows I'm thinking about systems that support and use UCS2 or UTF8 and where . or other common characters does not have special meaning for the filesystem. Using POSIX as the basis would properly not be enough as it's either to lax or to strict. I think Windows NTFS/VFAT32 + Kernel limits on characters might be a good basis: http://en.wikipedia.org/wiki/Filename * So paths can be up to 259 characters long * No characters in the range 0x01-0x1F * No control characters * Non of the following characters: * : ? \ / |. * Directory or filename up to 255 characters long * Only Unicode that fits in UCS-2(the 16bit subset) Any system specific restrictions would not apply like AUX, CLOCK$, COM, etc. would not apply and the programmer would be allow to shoot him/herself in the foot. Besides that, a simple check on Unix for what the locale is set to might also be nice, so we don't write UTF8 files on a filesystem where the rest for the files are in Latin1. Regards Troels.
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
2009/8/18 Timothy S. Nelson wayl...@wayland.id.au: On Tue, 18 Aug 2009, Mark J. Reed wrote: It's not in the revised spec, but I think that, even though we've revived chdir, we should still have it so that changing $*CWD will do a chdir under the hood. While in the spirit of TIMTOWTDI, having a magic variable that behaves differently from other variables when it's being set would be rather odd. -- Carlin
$*CWD and chdir()
On 2009-Aug-18, at 3:27 am, Timothy S. Nelson wrote:
On Tue, 18 Aug 2009, David Green wrote:
Maybe setting $*CWD just calls chdir() under the hood? Same
implementation, brand new shiny Perl-style interface!
That was my intent, but we had some discussions on IRC about the
whys and wherefores, and it will return as soon as I do my next
commit (hopefully sometime within the next 4-5 hours). Unless you
can think of a good way to do relative paths.
In my naiveté, I would do:
class IO::CurrentDir; # the type of $*CWD
sub STORE($self: IO::Path $new)
{
chdir($new);
$self = getcwd();
}
or however that would work in P6. It may have problems, but by
definition they're the same problems as chdir() has. What am I missing?
On 2009-Aug-18, at 3:12 am, Jan Ingvoldstad wrote:
It may seem cool, but I don't like secondary effects like that. They
break the principle of least surprise.
It doesn't seem that surprising to me, especially after seeing the
docs the first time. Are there environments where you can set a
variable like $*CWD and it doesn't do something like chdir?
(And we can always keep chdir() as well, so old dogs aren't forced to
learn new tricks.)
On 2009-Aug-18, at 3:52 am, Mark J. Reed wrote:
If $*CWD is really a Path object and not a Str, then it should be easy
to use mutator methods to change to a relative directory and do other
chdir()ish things. Say, concatenation works in terms of path
components, for instance:
$*CWD ~= $subdir; # chdir($subdir)
Yes. Though $*CWD = subdir should also work; subdir is not the
same path as /subdir, so it knows whether you're assigning a
relative path or not. Or rather, our path-type would know, and
implicitly prepend the current dir when it parses/forms the actual
pathname, so $CWD would effectively get a fully specified path every
time.
With a method for getting the parent:
given $*CWD { $_ = $_.up ~ $sibling } # chdir(../$sibling)
I like that.
and so on. My favorite kshism is cd old new which does a
search/replace on the current working directory; the bash equivalent
cd ${PWD/old/new} which is not quite as handy. $*CWD could make
that simple, too.
Ditto.
-David
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
On Tue, Aug 18, 2009 at 12:54 PM, Troels Liebe Bentsent...@rapanden.dk wrote: My idea with portable by default was only portability for modern Unix and modern Windows. So DOS and VMS limitations would not apply. The problem of enforcing truly portable filenames is that the files names get too restrictive and for most applications targeting 98% of systems out there would be enough. That's a decent enough point, but it may be unwise to ignore legacy systems that where Perl 5 is in common use, unless we want to shed that userbase. (Mark this down as a I don't know, and I don't have a stake in it, but…) With modern Unix/Windows I'm thinking about systems that support and use UCS2 or UTF8 and where . or other common characters does not have special meaning for the filesystem. We also need to keep in mind the Unicode problems between certain unixy platforms (i.e. MacOS X vs. most if not all the rest). If I recall correctly, the internal Unicode format chosen for Perl 6 is incompatible with MacOS X, because MacOS X implemented Unicode support at a time when the standard as we know it today wasn't finalized. This has bearing on filenames, and MacOS X isn't a small enough platform that it can simply be ignored, either. Besides that, a simple check on Unix for what the locale is set to might also be nice, so we don't write UTF8 files on a filesystem where the rest for the files are in Latin1. The locale doesn't say what format the filenames are on the filesystem, though, merely the current user's language preferences may be. That can't really be trusted, at least not for filename comparison purposes. But I agree that it's sensible to default to the locale's settings regarding character encoding. -- Jan
r28020 - docs/Perl6/Spec
Author: jani Date: 2009-08-18 13:18:13 +0200 (Tue, 18 Aug 2009) New Revision: 28020 Modified: docs/Perl6/Spec/S16-io.pod Log: Rephrasing for clarity, also changed POSIX to portable POSIX where appropriate Modified: docs/Perl6/Spec/S16-io.pod === --- docs/Perl6/Spec/S16-io.pod 2009-08-18 10:16:37 UTC (rev 28019) +++ docs/Perl6/Spec/S16-io.pod 2009-08-18 11:18:13 UTC (rev 28020) @@ -103,14 +103,13 @@ =head3 Default constraints -The default paths are portable paths. These are POSIX-compatible (see -POSIX.1-2008 sections4.7 and 3.276). If -platform/filesystem specific behavior is needed it should be shown in -the code by applying different sets of constraints (see below). +The default paths are portable POSIX paths (see POSIX.1-2008 sections +4.7 and 3.276). If platform/filesystem specific behavior is needed, +specific constraints should be applied as needed (see below). The default constraints are to only allow / as separator and only allows -POSIX filenames. That means A-Z, a-z, 0-9, period, underscore, and -hyphen. Additionally, hyphen may not be the first character in the path. +portable POSIX filenames. That means A-Z, a-z, 0-9, period, underscore, +and hyphen. Additionally, hyphen may not be the first character in the path. Any path that starts with a / is considered an absolute path, otherwise the path is considered relative.
Re: Filename literals
On 2009-Aug-17, at 8:36 am, Jon Lang wrote:
Timothy S. Nelson wrote:
Well, my main thought in this context is that the stuff that
can be
done to the inside of a file can also be done to other streams -- TCP
sockets for example (I know, there are differences, but the two are
a lot
the same), whereas metadata makes less sense in the context of TCP
sockets;
But any IO object might have metadata; some different from the
metadata you traditionally get with files, and some the same, e.g.
$io.size, $io.times{modified}, $io.charset, $io.type.
if (path{/path/to/file}.e) {
@lines = slurp(path{/path/to/file});
}
(I'm using one of David's suggested syntaxes above, but I'm
not
closely attached to it).
I suggested variations along the line of: io /path/to/file. It
amounts to much the same thing, but it's important conceptually to
distinguish a pathname from the thing it names. (A path doesn't have
a modification date, a file does.) Also, special quoting/escaping
could apply to other things, not limited to filenames. That said, I
don't think it's unreasonable to want to combine both operations for
brevity, but the io-constructor should have built-in path parsing, not
the other way around.
I guess what I'm saying here is that I think we can do the
things
without people having to worry about the objects being separate
unless they
care. So, separate objects, but hide it as much as possible. Is
that
something you're fine with?
Yes -- to me that means some class/role that wraps up all the pieces
together, but all the separate components are still there underneath.
But I'm not too bothered about how it's implemented as long as it's
transparent for casual use.
my $file = io p[/some/file];
my $contents = $file.data;
my $mod-date = $file.times{modified};
my $size = $file.size;
Pathnames still are strings, so that's fine. In fact, there are
different
As for pathnames being strings, you may be right FSVO
string. But
I'd say that, while they may be strings, they're not Str, but they
do Str
Agreed, pathnames are almost strings, but worth distinguishing
conceptually. There should be a URL type that does Str.
Actually, there are other differences, like case-insensitivity and
illegal chars. Unfortunately, those depend on the given filesystem.
As long as you're dealing with one FS at a time, that's OK; it
probably means we have IO::Name::ext3, IO::Name::NTFS, IO::Name::HFS,
etc. But what happens when you cross FS-barriers? Does a case-
sensitive name match a case-insensitive one? Is filename-equality not
commutative or not transitive? If you're looking for a filename foo
on Mac/Win, then a file actually called FOO matches; but on Unix it
wouldn't.
(Actually, Macs can do both IO::Name::HFS::case-insensitive and
IO::Name::HFS::case-sensitive. Eek.)
I'd like Perl 6's treatment of filenames to be smart enough that
smart-matching any of these pairs of alternative spellings would
result in a successful match. So while I'll agree that filenames
are string-like, I really don't want them to _be_ strings.
Well, the *files* are the same, but the pathnames are different. I'm
not sure whether some differences in spelling should be ignored by
default or not. There are actually several different kinds; S32 has a
method realpath, but I think canonical is a better name, because
aliases can be just as real as the canonical path, e.g. a web page
with multiple addresses. Or hard links rather than soft links --
though in that case, there is no one canonical path. It may not
even be possible to easily tell if there is one or not.
Some ways in which different paths can be considered equivalent:
Spelling: C:\PROGRA~1, case-insensitivity
Simplification: foo/../bar/ to bar/
Resolution: of symlinks/shortcuts
Content-wise: hard links/multiple addresses
Depending on the circumstances, you might want any of those to count
as the same file; or none of them. We'll need methods for each sort
of transformation, $path.canonical, $path.normalize, $path.simplify,
etc. Two high-level IO objects are the same, regardless of path, if
$file2 =:= $file2 (which might compare inodes, etc.). There should be
a way to set what level of sameness applies in a given lexical scope;
perhaps the first two listed above are a reasonable default to start
with.
There's something that slightly jars me here... I don't like the
quotation returning an IO object.
But doesn't normal quoting return a Str object? And regex quoting
return an object (Regex? Match? Something, anyway).
Certainly, but a regex doesn't produce a Signature object, say. I
don't object to objects, just to creating objects, then doing
something with them, then returning another kind of object, and
calling that parsing. If we're parsing the characters, we should
end up with an IO::Name. If
Re: $*CWD and chdir()
2009/8/18 David Green david.gr...@telus.net: On 2009-Aug-18, at 3:27 am, Timothy S. Nelson wrote: On Tue, 18 Aug 2009, David Green wrote: or however that would work in P6. It may have problems, but by definition they're the same problems as chdir() has. What am I missing? chdir is a familar function with predictable behaviour. $*CWD, as a variable that magically changes to something other than what it was set to, is unfamiliar and unpredictable. Now there's nothing wrong with introducing new, unfamiliar functionality, if it provides a discernible benefit, but that doesn't seem to be the case here. -- Carlin
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
On Tue, Aug 18, 2009 at 13:10, Jan Ingvoldstadfrett...@gmail.com wrote:
On Tue, Aug 18, 2009 at 12:54 PM, Troels Liebe Bentsent...@rapanden.dk
wrote:
My idea with portable by default was only portability for modern Unix and
modern Windows. So DOS and VMS limitations would not apply. The problem of
enforcing truly portable filenames is that the files names get too
restrictive and for most applications targeting 98% of systems out there
would
be enough.
That's a decent enough point, but it may be unwise to ignore legacy
systems that where Perl 5 is in common use, unless we want to shed
that userbase. (Mark this down as a I don't know, and I don't have a
stake in it, but…)
I completely agree and we might make a p:posix{} or p:strict{} to handle that.
But one thing to remember is that having the default p{} allow characters and
formats that is not supported on VMS or DOS, only means the programmer won't
get a compiler error. In other words he is only a little better off than using
a normal string or Q{}. Also in cases where systems has special requirements
the local version should be used so, fx. VMS would have p:vms{} and DOS
p:dos{}.
The defaults should handle most cases and limiting path's to only ASCII might
be a bit much. For the default path literal to be useful it should work in most
normal cases, and I would say international characters would be a normal case.
What I would like to go for is the lowest reasonable common denominator for the
default p{}, for me at least this is MacOSX, Windows XP, Linux, *BSD, etc.
With modern Unix/Windows I'm thinking about systems that support and use UCS2
or UTF8 and where . or other common characters does not have special
meaning
for the filesystem.
We also need to keep in mind the Unicode problems between certain
unixy platforms (i.e. MacOS X vs. most if not all the rest).
If I recall correctly, the internal Unicode format chosen for Perl 6
is incompatible with MacOS X, because MacOS X implemented Unicode
support at a time when the standard as we know it today wasn't
finalized.
This has bearing on filenames, and MacOS X isn't a small enough
platform that it can simply be ignored, either.
I guess if this puts limits of what characters can be in file names it should
also go in the default limits. But how Perl 6 stores the Path internally is not
really important, so long as it can be automatically converted with out
changing meaning before it is parsed to the OS. So what we should limit is what
can not be automatically converted.
Regards Troels.
Re: $*CWD and chdir()
On 2009-Aug-18, at 4:59 am, Carlin Bingham wrote: 2009/8/18 Timothy S. Nelson wayl...@wayland.id.au: It's not in the revised spec, but I think that, even though we've revived chdir, we should still have it so that changing $*CWD will do a chdir under the hood. While in the spirit of TIMTOWTDI, having a magic variable that behaves differently from other variables when it's being set would be rather odd. But really, it isn't different After all, a current path IS just a string; it's a string that shells helpfully insert for you at certain points to save you some typing. The automatic insertion may be magical, but the string itself is quite ordinary. The metaphor of being in a directory is quite fascinating, really. Directories are not something you can be in -- they're lists that hang on the walls of office buildings, or get printed on the pages of a phone book. They're pointers, dir-ections to where you can find something -- an office, a telephone, or a file on a disk. Literally *on* the disk, not in it (disk platters are flat!). But this image of working in a directory seems to come quite easily and naturally. It wouldn't seem magical if we always wrote like this: ls $PWD/foo/bar PWD = $PWD/foo ls $PWD/bar That would still save a lot of typing, but not having to type the $PWD saves even more. But perhaps the apparent magic is that $*CWD = /foo sets the CWD to /foo, but setting it to foo does not set the CWD to foo, but rather to $OLDCWD/foo. But that's not $*CWD's doing, that's our path-quoting. ~ p[/foo/bar] eq /foo/bar# path literal cast to Str ~ p[foo/bar] eq $CWD/foo/bar Not so strange to anyone familiar with the idea of relative paths, and no more magical than... say, the fact that a literal series of digits gets parsed as though it had an implicit 0d in front of it. (Of course, I suspect that $*CWD should be able to be set to a plain Str, but the Str will be cast to an IO::Path because that's what $*CWD.STORE() will take in its signature.) -David
Re: $*CWD and chdir()
On Tue, Aug 18, 2009 at 1:02 PM, David Greendavid.gr...@telus.net wrote: On 2009-Aug-18, at 3:12 am, Jan Ingvoldstad wrote: It may seem cool, but I don't like secondary effects like that. They break the principle of least surprise. It doesn't seem that surprising to me, especially after seeing the docs the first time. Are there environments where you can set a variable like $*CWD and it doesn't do something like chdir? Yes, and that's normal and expected behaviour. viking...@shell:~$ uname -a Linux shell 2.4.37.5 #1 Sun Aug 16 12:47:03 CEST 2009 i686 unknown unknown GNU/Linux viking...@shell:~$ bash --version GNU bash, version 2.05b.0(1)-release (i486-slackware-linux-gnu) Copyright (C) 2002 Free Software Foundation, Inc. viking...@shell:~$ mkdir test viking...@shell:~$ touch test/testfile viking...@shell:~$ cd test viking...@shell:~/test$ ls testfile viking...@shell:~/test$ pwd /home/1/v/vikingmud/test viking...@shell:~/test$ echo $PWD /home/1/v/vikingmud/test viking...@shell:~/test$ PWD=foo/notreallyadirectory viking...@shell:foo/notreallyadirectory$ ls testfile viking...@shell:foo/notreallyadirectory$ pwd /home/1/v/vikingmud/test viking...@shell:foo/notreallyadirectory$ echo $PWD foo/notreallyadirectory j...@krakas ~ uname -a Darwin krakas.ELIDED 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 j...@krakas ~ bash --version GNU bash, version 3.2.17(1)-release (i386-apple-darwin9.0) Copyright (C) 2005 Free Software Foundation, Inc. j...@krakas ~ mkdir test j...@krakas ~ touch test/testfile j...@krakas ~ cd test j...@krakas ~/test ls testfile j...@krakas ~/test pwd /Users/jani/test j...@krakas ~/test echo $PWD /Users/jani/test j...@krakas ~/test PWD=foo/notreallyadirectory j...@krakas foo/notreallyadirectory ls testfile j...@krakas foo/notreallyadirectory pwd /Users/jani/test j...@krakas foo/notreallyadirectory echo $PWD foo/notreallyadirectory -- Jan
Default path restrictions
On 2009-Aug-18, at 1:24 am, pugs-comm...@feather.perl6.nl wrote:
+=head3 Default constraints
+
+The default p{} only allows / as separator and does not allow
path elements to contain
+characters that won't work on modern Windows and Unix like \ / ? %
* : | ,
+etc. The reason for this is that portable paths are the default. If
+platform/filesystem specific behavior is really needed it should be
shown in
+the code by applying different sets of constraints (see below).
I dunno, doesn't portability in the 21st century mean compatibility
with the web rather than with DOS??
I'd be inclined to default to whatever works with the user's own OS/
FS. Of course, if you don't like any default setting in P6, all you
need to do is slap use something-else into your ~/Policy.pm file, so
it's not a big deal. Nevertheless, there's more to respecting other
systems than simply doing without punctuation. For example, a
suitable pathname on Unix might be:
~/.foorc
Whereas on a Mac, it might be more polite to use:
~/Library/Application Support/Foo/Startup Settings
which is certainly beyond the scope of p{}-quoting.
-David
Re: $*CWD and chdir()
It would be nice if the bikeshed had aluminum siding. Er, I mean, if chdir() changed *CWD and vice-versa, though I'm not sure offhand how best to code that in idiomatic P6 to avoid the infinite recursion. Anyway, at the very least, a readonly *CWD holding a cached idea of the current dir is good. Not having to call getcwd() is a definite performance win. And if it functions like the POSIX shell PWD in terms of tracking symlinks and translating relative pathnames to match the apparent cwd instead of the physical one, so much the better. That is, in ksh/bash, if I do mkdir -p foo/bar/baz cd foo ln -s bar/baz . cd baz Now getcwd() (via e.g. /bin/pwd) says I'm in .../foo/bar/baz. But $PWD (and the shell builtin pwd) says .../foo/baz. And even though the directory entry .. is a link to .../foo/bar, if I do cd .. I will be back in .../foo, because the shell translates it into the equivalent of 'cd $(basename $PWD) '. Of course, other programs don't apply this logic to their arguments, which can lead to confusion when e.g. cd .. cat myfile yields a different result from cat ../myfile. But in general, this potential confusion was deemed worth it for the added transparency and utility of symbolic links. So perhaps a similar distinction between $*CWD and getcwd() would be useful in P6. It would cut way down on the not getting back what you put in problem with assigning to $*CWD. We could minimize that issue even further by not allowing the assignment of relative pathnames, only absolute ones (which of course can be constructed by simple ops on the current value). On 8/18/09, Carlin Bingham car...@theintersect.org wrote: 2009/8/18 David Green david.gr...@telus.net: On 2009-Aug-18, at 3:27 am, Timothy S. Nelson wrote: On Tue, 18 Aug 2009, David Green wrote: or however that would work in P6. It may have problems, but by definition they're the same problems as chdir() has. What am I missing? chdir is a familar function with predictable behaviour. $*CWD, as a variable that magically changes to something other than what it was set to, is unfamiliar and unpredictable. Now there's nothing wrong with introducing new, unfamiliar functionality, if it provides a discernible benefit, but that doesn't seem to be the case here. -- Carlin -- Sent from my mobile device Mark J. Reed markjr...@gmail.com
Re: $*CWD and chdir()
Er, that basename down there should be a dirname, for those playing along at home. Memo to self: do not type long screeds on Blackberry... On 8/18/09, Mark J. Reed markjr...@gmail.com wrote: It would be nice if the bikeshed had aluminum siding. Er, I mean, if chdir() changed *CWD and vice-versa, though I'm not sure offhand how best to code that in idiomatic P6 to avoid the infinite recursion. Anyway, at the very least, a readonly *CWD holding a cached idea of the current dir is good. Not having to call getcwd() is a definite performance win. And if it functions like the POSIX shell PWD in terms of tracking symlinks and translating relative pathnames to match the apparent cwd instead of the physical one, so much the better. That is, in ksh/bash, if I do mkdir -p foo/bar/baz cd foo ln -s bar/baz . cd baz Now getcwd() (via e.g. /bin/pwd) says I'm in .../foo/bar/baz. But $PWD (and the shell builtin pwd) says .../foo/baz. And even though the directory entry .. is a link to .../foo/bar, if I do cd .. I will be back in .../foo, because the shell translates it into the equivalent of 'cd $(basename $PWD) '. Of course, other programs don't apply this logic to their arguments, which can lead to confusion when e.g. cd .. cat myfile yields a different result from cat ../myfile. But in general, this potential confusion was deemed worth it for the added transparency and utility of symbolic links. So perhaps a similar distinction between $*CWD and getcwd() would be useful in P6. It would cut way down on the not getting back what you put in problem with assigning to $*CWD. We could minimize that issue even further by not allowing the assignment of relative pathnames, only absolute ones (which of course can be constructed by simple ops on the current value). On 8/18/09, Carlin Bingham car...@theintersect.org wrote: 2009/8/18 David Green david.gr...@telus.net: On 2009-Aug-18, at 3:27 am, Timothy S. Nelson wrote: On Tue, 18 Aug 2009, David Green wrote: or however that would work in P6. It may have problems, but by definition they're the same problems as chdir() has. What am I missing? chdir is a familar function with predictable behaviour. $*CWD, as a variable that magically changes to something other than what it was set to, is unfamiliar and unpredictable. Now there's nothing wrong with introducing new, unfamiliar functionality, if it provides a discernible benefit, but that doesn't seem to be the case here. -- Carlin -- Sent from my mobile device Mark J. Reed markjr...@gmail.com -- Sent from my mobile device Mark J. Reed markjr...@gmail.com
Re: $*CWD and chdir()
On 2009-Aug-18, at 5:48 am, Jan Ingvoldstad wrote: On Tue, Aug 18, 2009 at 1:02 PM, David Greendavid.gr...@telus.net wrote: It doesn't seem that surprising to me, especially after seeing the docs the first time. Are there environments where you can set a variable like $*CWD and it doesn't do something like chdir? Yes, and that's normal and expected behaviour. Huh. Thank you, I did not know that. It makes sense (in that I understand what's going on now that I see it, and indeed it seems almost obvious), but I certainly couldn't call it expected because I didn't. And I can guarantee I'm not the only one; in fact, I have no qualms about classifying that as a bug. -David
Re: Filename literals
Reading this discussion, I'm getting the feeling that filename literals are increasingly getting magical, something that I don't think is a good development. The only sane way to deal with filenames is treating them as opaque binary strings, making any more assumptions is bound to get you into trouble. I don't want to deal with Windows' strange restrictions on characters when I'm working on Linux. I don't want to deal with any other platform's particularities either. Portability should be positive, not negative IMNSHO. As for comparing paths: reimplementing logic that belongs to the filesystem sounds like really Bad Idea™ to me. Two paths can't be reliably compared without choosing to make some explicit assumptions, and I don't think Perl should make such choices for the programmer. Leon Timmermans
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
On Tue, Aug 18, 2009 at 6:59 AM, Carlin Binghamcar...@theintersect.org wrote: 2009/8/18 Timothy S. Nelson wayl...@wayland.id.au: On Tue, 18 Aug 2009, Mark J. Reed wrote: It's not in the revised spec, but I think that, even though we've revived chdir, we should still have it so that changing $*CWD will do a chdir under the hood. You're quoting the wrong person. That wasn't me. -- Mark J. Reed markjr...@gmail.com
Re: S26 - The Next Generation
On 2009-Aug-18, at 3:29 am, Jan Ingvoldstad wrote: In general, executable documentation is a bad thing. It's been shown to be a bad thing many times over. Well, tons of programs have --help options, which could be considered executable documentation, and it's very useful. Emacs brags about being self-documenting. It's worth it because it's more work the computer can do instead of humans (and often do a lot better). It's annoying when a printed book says the default setting is $foo when it isn't because somebody changed the defaults, or the config file is at $some/$path when it isn't because it was installed using a non-standard layout -- but it's understandable, because there's not much you can do about that. It's a lot more frustrating when you're looking at docs on a programmable computer that actually knows the real settings/paths/etc. and *could* tell you, but doesn't. But it's a lot more than that: although it can help the end-user, it also helps authors. I can weave together my (il)literate POD in the most convoluted way Pod6::Order::Labyrinthine can handle. I can have it pull values out of my code so that's impossible for the docs to get out of date because I forgot to change them. That's still a big help even if my end users look only at a static copy of the docs once they're produced. If we absolutely must have some sort of executable documentation, then if I could, I would insist that it wouldn't be a feature complete language. That is: absolutely no IO in the language, no way of executing code that's foreign to the doc, and so on. Well, perl-doc can't run any POD-executing modules that never get installed. But surely it's possible to forbid IO, no? Disallow any actual IO functions, as well as anything that could be used to sneak them in (eval). I guess you'd want to allow Perl itself to load installed modules (but maybe nothing from the current dir, or outside the official library location). Having perl-doc run in lock-down mode, or run in display-precompiled-static-file-only mode by default might be a good idea, though I'm not convinced it's completely necessary. -David
Re: Filename literals
On Tue, 18 Aug 2009, David Green wrote:
On 2009-Aug-17, at 8:36 am, Jon Lang wrote:
Timothy S. Nelson wrote:
Well, my main thought in this context is that the stuff that can be
done to the inside of a file can also be done to other streams -- TCP
sockets for example (I know, there are differences, but the two are a lot
the same), whereas metadata makes less sense in the context of TCP
sockets;
But any IO object might have metadata; some different from the metadata you
traditionally get with files, and some the same, e.g. $io.size,
$io.times{modified}, $io.charset, $io.type.
Ok, now you're giving me ideas :).
[snipped a bit and moved it further down the e-mail]
I guess what I'm saying here is that I think we can do the things
without people having to worry about the objects being separate unless
they
care. So, separate objects, but hide it as much as possible. Is that
something you're fine with?
Yes -- to me that means some class/role that wraps up all the pieces
together, but all the separate components are still there underneath. But
I'm not too bothered about how it's implemented as long as it's transparent
for casual use.
my $file = io p[/some/file];
my $contents = $file.data;
my $mod-date = $file.times{modified};
my $size = $file.size;
That sounds like the kind of thing I'm heading for.
Pathnames still are strings, so that's fine. In fact, there are
different
As for pathnames being strings, you may be right FSVO string. But
I'd say that, while they may be strings, they're not Str, but they do Str
Agreed, pathnames are almost strings, but worth distinguishing
conceptually. There should be a URL type that does Str.
Actually, there are other differences, like case-insensitivity and illegal
chars. Unfortunately, those depend on the given filesystem. As long as
you're dealing with one FS at a time, that's OK; it probably means we have
IO::Name::ext3, IO::Name::NTFS, IO::Name::HFS, etc. But what happens when
you cross FS-barriers? Does a case-sensitive name match a case-insensitive
one? Is filename-equality not commutative or not transitive? If you're
looking for a filename foo on Mac/Win, then a file actually called FOO
matches; but on Unix it wouldn't.
(Actually, Macs can do both IO::Name::HFS::case-insensitive and
IO::Name::HFS::case-sensitive. Eek.)
I think it should depend on the set of constraints involved.
I'd like Perl 6's treatment of filenames to be smart enough that
smart-matching any of these pairs of alternative spellings would result
in a successful match. So while I'll agree that filenames are string-like,
I really don't want them to _be_ strings.
Well, the *files* are the same, but the pathnames are different. I'm not
sure whether some differences in spelling should be ignored by default or
not. There are actually several different kinds; S32 has a method
realpath, but I think canonical is a better name, because aliases can be
just as real as the canonical path, e.g. a web page with multiple
addresses. Or hard links rather than soft links -- though in that case,
there is no one canonical path. It may not even be possible to easily tell
if there is one or not.
Some ways in which different paths can be considered equivalent:
Spelling: C:\PROGRA~1, case-insensitivity
Simplification: foo/../bar/ to bar/
Resolution: of symlinks/shortcuts
Content-wise: hard links/multiple addresses
Depending on the circumstances, you might want any of those to count as the
same file; or none of them. We'll need methods for each sort of
transformation, $path.canonical, $path.normalize, $path.simplify, etc. Two
high-level IO objects are the same, regardless of path, if $file2 =:=
$file2 (which might compare inodes, etc.). There should be a way to set what
level of sameness applies in a given lexical scope; perhaps the first two
listed above are a reasonable default to start with.
Ok, my next commit will have canonpath (stolen directly from p5's
File::Spec documentation), which will do No physical check on the filesystem,
but a logical cleanup of a path, and realpath (idea taken from p5's Cwd
documentation), which will resolve symlinks, etc, and provide an absolute
path. Oh, and resolvepath, which does both. I'm not quite sure I followed
all your discussion above -- have I left something out?
Anyway, my assumption is that there should be a number of comparison
options. Since we do Str, we should get string comparison for free. But I'm
expecting other options at other levels, but have no idea how or what at this
point.
There's something that slightly jars me here... I don't like the
quotation returning an IO object.
But doesn't normal quoting return a Str object? And regex quoting return
an object (Regex? Match? Something, anyway).
Certainly, but a regex doesn't produce a Signature object, say. I don't
object to objects, just to creating objects,
Re: Filename literals
Leon (): Reading this discussion, I'm getting the feeling that filename literals are increasingly getting magical, something that I don't think is a good development. The only sane way to deal with filenames is treating them as opaque binary strings, making any more assumptions is bound to get you into trouble. I don't want to deal with Windows' strange restrictions on characters when I'm working on Linux. I don't want to deal with any other platform's particularities either. Portability should be positive, not negative IMNSHO. As for comparing paths: reimplementing logic that belongs to the filesystem sounds like really Bad Idea™ to me. Two paths can't be reliably compared without choosing to make some explicit assumptions, and I don't think Perl should make such choices for the programmer. Very nicely put. We can't predict the future, but in creating something that'll at least persist through the next decade, let's not do elaborate things with lots of moving parts. Let's make a solid ground to stand on; something so stable that it works uphill and underwater. People with expertise and tuits will write the facilitating modules. PerlJam To quote Kernighan and Pike: Simplicity. Clarity. Generality. moritz_ I agree. Matt-W magic can always be added with module goodness // Carl
Re: $*CWD and chdir()
On Tue, Aug 18, 2009 at 2:33 PM, David Green david.gr...@telus.net wrote:
Huh. Thank you, I did not know that. It makes sense (in that I
understand what's going on now that I see it, and indeed it seems almost
obvious), but I certainly couldn't call it expected because I didn't. And
I can guarantee I'm not the only one; in fact, I have no qualms about
classifying that as a bug.
You think it's a bug that PWD=/etc doesn't change your working directory
to /etc in bash?
Please tell me you're joking.
The environment variables are generally just descriptive variables. If you
mess with them, they may no longer have bearing on reality. That is also
expected behaviour; if you shoot yourself in the foot, you may get hurt.
It can also be said to be expected behaviour because that's the way it has
been behaving for maybe as long as environment variables have been in
existence in Unix systems.
Here's another example of something that, if I understand you correctly, you
find as unexpected behaviour:
j...@krakas ~ USER=root
j...@krakas ~ echo $USER
root
# Am i root now?
j...@krakas ~ whoami
jani
# I'm not root.
While there have been programs assuming that %ENV{USER} indicates who the
current user is, and adjusting their behaviour based on that, such behaviour
has generally been classified as a security vulnerability, and rightly so.
--
Jan
Re: Filename literals
On Tue, Aug 18, 2009 at 3:20 PM, Carl Mäsak cma...@gmail.com wrote: Let's make a solid ground to stand on; something so stable that it works uphill and underwater. People with expertise and tuits will write the facilitating modules. PerlJam To quote Kernighan and Pike: Simplicity. Clarity. Generality. moritz_ I agree. Matt-W magic can always be added with module goodness I agree with this principle. The discussion has been (and probably still will be) fruitful anyway, if only in illuminating the challenges with multi-platform and multi-filesystem support, some of the things we need to consider for that and how. -- Jan
Re: Filename literals
+1 Carl Mäsak wrote: Very nicely put. We can't predict the future, but in creating something that'll at least persist through the next decade, let's not do elaborate things with lots of moving parts. Let's make a solid ground to stand on; something so stable that it works uphill and underwater. People with expertise and tuits will write the facilitating modules. PerlJam To quote Kernighan and Pike: Simplicity. Clarity. Generality. moritz_ I agree. Matt-W magic can always be added with module goodness
Re: $*CWD and chdir()
On Tue, Aug 18, 2009 at 9:26 AM, Jan Ingvoldstadfrett...@gmail.com wrote: You think it's a bug that PWD=/etc doesn't change your working directory to /etc in bash? Please tell me you're joking. It's not that unreasonable. Given a variable that magically changes depending on your working directory, having your working directory change when you set that variable is eminently plausible. Especially since the cwd is completely under the shell's control. And changing dirs by setting PWD wouldn't get you any capability you don't have anyway via the cd builtin. Notably, while many of the special shell parameters have documented set behavior (setting RANDOM seeds the random number generator; many special parameters are readonly; others lose their magic entirely when unset), the behavior of setting PWD is not specified. So a shell could have PWD= do a cd() and even be within compliance. Here's another example of something that, if I understand you correctly, you find as unexpected behaviour: j...@krakas ~ USER=root If that were going to work, it would presumably work like su(1): j...@krakas ~ USER=root Password: j...@krakas ~ # _ But USER isn't even a shell-maintained variable. It's set by login(); the shell just inherits it. A better example would be UID - which is readonly. -- Mark J. Reed markjr...@gmail.com
Re: $*CWD and chdir()
On Tue, 18 Aug 2009, Jan Ingvoldstad wrote:
On Tue, Aug 18, 2009 at 2:33 PM, David Green david.gr...@telus.net wrote:
Huh. Thank you, I did not know that. It makes sense (in that I
understand what's going on now that I see it, and indeed it seems almost
obvious), but I certainly couldn't call it expected because I didn't. And
I can guarantee I'm not the only one; in fact, I have no qualms about
classifying that as a bug.
You think it's a bug that PWD=/etc doesn't change your working directory
to /etc in bash?
Please tell me you're joking.
..but Perl is more magic than bash :). Seriously, I can see both
sides of the argument, and I'm leaning towards the $*CWD = chdir idea (as an
option if people want to use it), but I realise that a lot of people are
leaning the other way. So I'll argue for it, but don't care if I lose :).
The environment variables are generally just descriptive variables. If you
mess with them, they may no longer have bearing on reality. That is also
expected behaviour; if you shoot yourself in the foot, you may get hurt.
It can also be said to be expected behaviour because that's the way it has
been behaving for maybe as long as environment variables have been in
existence in Unix systems.
Here's another example of something that, if I understand you correctly, you
find as unexpected behaviour:
j...@krakas ~ USER=root
j...@krakas ~ echo $USER
root
# Am i root now?
j...@krakas ~ whoami
jani
# I'm not root.
While there have been programs assuming that %ENV{USER} indicates who the
current user is, and adjusting their behaviour based on that, such behaviour
has generally been classified as a security vulnerability, and rightly so.
I think David Green's argument would be that, in something as magic as
Perl, doing USER=root should call setuid(), and chuck an error when it fails.
And note that Perl 5 allows you to do exactly this, if I understand the
documentation for EFFECTIVE_USER_ID in the perlvar manpage correctly.
So, if P5 does it for some global (note: global != environment)
variables, then why not do it for some in P6? Note that no-one's stopping you
from doing this:
chdir(/usr/bin);
say %*ENVPWD -- $*CWD\n
$*CWD = /usr/lib;
%*ENVPWD = /foo/notadirectory;
say %*ENVPWD -- $*CWD\n
...which would print:
/usr/bin/ -- /usr/bin
/foo/notadirectory -- /usr/lib
So, you can still set %*ENVPWD how you want, but $*CWD ties to
getcwd and chdir the way some other people want. Yes?
:)
-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am |
-
BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-
-END GEEK CODE BLOCK-
Re: Filename literals
On Tue, 18 Aug 2009, Leon Timmermans wrote:
Reading this discussion, I'm getting the feeling that filename
literals are increasingly getting magical, something that I don't
think is a good development. The only sane way to deal with filenames
is treating them as opaque binary strings, making any more assumptions
is bound to get you into trouble. I don't want to deal with Windows'
strange restrictions on characters when I'm working on Linux. I don't
want to deal with any other platform's particularities either.
Portability should be positive, not negative IMNSHO.
Sounds to me like you need p:bin{/path/to/file} -- that does what you
want it to. I'll make it more obvious in the S16 documentation.
As for comparing paths: reimplementing logic that belongs to the
filesystem sounds like really Bad Idea? to me. Two paths can't be
reliably compared without choosing to make some explicit assumptions,
and I don't think Perl should make such choices for the programmer.
That's why I want multiple comparison options, so that people have to
explicitly choose what they want. How to do this, though, I'm unsure.
:)
-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am |
-
BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-
-END GEEK CODE BLOCK-
Re: $*CWD and chdir()
2009/8/19 Timothy S. Nelson wayl...@wayland.id.au: So, if P5 does it for some global (note: global != environment) variables, then why not do it for some in P6? Because if (for some reason) I do: $ = 5; # Which calls setuid(5); print $; # 5 Whereas: $*CWD = '..'; # which hypothetically calls chdir '..'; print $*CWD; # /home -- Carlin
Re: r90210 - in docs/Perl666/Spec: . S0S-upsetting-library
On 2009-Aug-18, at 7:05 am, Mark J. Reed wrote: On Tue, Aug 18, 2009 at 6:59 AM, Carlin Binghamcar...@theintersect.org wrote: 2009/8/18 Timothy S. Nelson wayl...@wayland.id.au: On Tue, 18 Aug 2009, Mark J. Reed wrote: It's not in the revised spec, but I think that, even though we've revived chdir, we should still have it so that changing $*CWD will do a chdir under the hood. You're quoting the wrong person. That wasn't me. Technically of course, he quoted Tim quoting you without any of the double-quoted material but with the quoted attribution referring to your non-quoted quote. I wish e-mail programs were smart enough to catch when somebody's text has all been snipped out but the dangling attribution hasn't. Hey, what if P6 had built-in mail software that used a Grammar to analyse messages and store the nested levels in a Tree structure -- we could have a special A: quoting mechanism for literal attributions, and maybe some variations like aa: to allow for interpolated names, or a:dates to parse -MM-DD, etc. as automatically inserted date formats. On could be a special macro so you don't even need quotes around an attribution line. Oh, and people use different languages to say On $date, $foo wrote, but that's pretty easy to fix: just include a working version of babelfish.com (it's just a few textareas -- you could probably whip it up in a day using Catalyst). Plus it should disallow / \ ? * $ @ % ☹ unless preceded by (##`=☞, and not run any executable code when you're looking at it. And there's a magic plural-\s (s/://g), but it works only if the attributee is Larry Wall. -David is it bedtime yet? Green
Re: $*CWD and chdir()
On Wed, 19 Aug 2009, Carlin Bingham wrote: 2009/8/19 Timothy S. Nelson wayl...@wayland.id.au: So, if P5 does it for some global (note: global != environment) variables, then why not do it for some in P6? Because if (for some reason) I do: $ = 5; # Which calls setuid(5); print $; # 5 Whereas: $*CWD = '..'; # which hypothetically calls chdir '..'; print $*CWD; # /home Ok, so suppose we only allowed direct assignment to absolute paths? - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: $*CWD and chdir()
On Tue, Aug 18, 2009 at 10:26 AM, Timothy S. Nelsonwayl...@wayland.id.au wrote: Ok, so suppose we only allowed direct assignment to absolute paths? Is there an echo in here? :) -- Mark J. Reed markjr...@gmail.com
Re: Filename literals
On Tue, Aug 18, 2009 at 15:20, Carl Mäsakcma...@gmail.com wrote:
Leon ():
Reading this discussion, I'm getting the feeling that filename
literals are increasingly getting magical, something that I don't
think is a good development. The only sane way to deal with filenames
is treating them as opaque binary strings, making any more assumptions
is bound to get you into trouble. I don't want to deal with Windows'
strange restrictions on characters when I'm working on Linux. I don't
want to deal with any other platform's particularities either.
Portability should be positive, not negative IMNSHO.
The whole reason filenames/paths is a mess to code if because they are treated
as binary strings in most cases. This is also why we have modules like
File::Spec and bunch more on CPAN all trying to do the same thing. And today if
I want to code something that works on all platforms I have to use that
instead. How can this be positive?
For me a Path literal is a way to get rid of all this bandage so we don't have
to bother with the strange restrictions later when we get a bug report from a
CPAN user. And there is nothing magical about it, no more so than if I ask for
the length of UTF8 string I expect get back the number of characters not the
number of bytes.
A path is a well defined size on all platforms and should be treated as such.
The main problems is that POSIX really never did cover this part too well. But
today we have Unicode and UTF8 and as such this is the de facto default on most
modern unix'es as most libraries and tools will write filenames in this format
if so defined in the locale.
Just writing binary data to a filename is bound to get you into trouble and you
will quickly find that many of the common C libraries will fail if locale and
filename does not match.
So even on Linux/Unix a path really not just any number of bytes with / as
delimiter. It depends on the locale and the encoding set for the file system
and not caring about that will get you into trouble.
But than again you always have the option of using p:unix{}, it's also a clear
way to signal you really don't care about portability and that this will only
work on Unix. Or you could even use Q{} as this pretty much will allow you to
anything.
As for comparing paths: reimplementing logic that belongs to the
filesystem sounds like really Bad Idea™ to me. Two paths can't be
reliably compared without choosing to make some explicit assumptions,
and I don't think Perl should make such choices for the programmer.
Getting any kind of path's from user input will require you to reimplement that
logic if you care about validate data before throwing it at the file system.
If you buy that paths are well defined types, then comparing paths should not
require making any assumptions. We can compare Unicode string without making
assumptions.
Very nicely put. We can't predict the future, but in creating
something that'll at least persist through the next decade, let's not
do elaborate things with lots of moving parts.
Let's make a solid ground to stand on; something so stable that it
works uphill and underwater. People with expertise and tuits will
write the facilitating modules.
PerlJam To quote Kernighan and Pike: Simplicity. Clarity. Generality.
moritz_ I agree.
Matt-W magic can always be added with module goodness
I completely agree we can't predict the future but we do have to make some sane
choices about how the default should work, who knows if UTF8 will still be hot
new thing in 10 years, but that's still the default assumption for much of Perl
6 if nothing else is known about the input we get.
And I totally agree path literals should not be magically, they should be well
defined and you should not suffer when using them because platform X or Y has
strange restrictions. But when finding the sane default we have to make
restrictions and POSIX's path is binary data, simply is to lax.
My idea about using the lowest common denominator for modern Unix and windows
was that we could get as much of Unicode in path names as possible without
breaking on modern platforms and as a way to get Simplicity, Clarity and
Generality into paths.
Because this will never be simple, clear or general:
File::Spec-catfile(qw(.. ext Sys Syslog macros.all));
or any of the other example that we can find:
http://www.google.com/codesearch?hl=enstart=10sa=Nq=FIle::Spec-%3Ecatfile
Regards Troels
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
On Tue, Aug 18, 2009 at 01:10:58PM +0200, Jan Ingvoldstad wrote:
On Tue, Aug 18, 2009 at 12:54 PM, Troels Liebe Bentsent...@rapanden.dk
wrote:
Besides that, a simple check on Unix for what the locale is set to might
also be
nice, so we don't write UTF8 files on a filesystem where the rest for the
files
are in Latin1.
The locale doesn't say what format the filenames are on the
filesystem, though, merely the current user's language preferences may
be.
We don't want to make the same mistakes as Python 3:
http://mail.python.org/pipermail/python-dev/2008-December/083856.html
The summary is that different file names in the same directory might be
in different encodings, and your programming language runtime sucks big time
if it doesn't offer you a way to iterate over all of them somehow, even if
you can't render their names.
[Consider a security critical program scanning using glob('*'), which gives
a clean bill of health because it opened all files and found no problems.]
I don't know how Python 3 resolved this.
Nicholas Clark
Re: $*CWD and chdir()
On Tue, Aug 18, 2009 at 3:52 PM, Mark J. Reed markjr...@gmail.com wrote:
On Tue, Aug 18, 2009 at 9:26 AM, Jan Ingvoldstadfrett...@gmail.com
wrote:
You think it's a bug that PWD=/etc doesn't change your working
directory
to /etc in bash?
Please tell me you're joking.
It's not that unreasonable.
I disagree, and I think I've explained why, and perhaps we won't get much
further.
But see below.
But USER isn't even a shell-maintained variable. It's set by login();
the shell just inherits it. A better example would be UID - which is
readonly.
I'm not sure what you mean by a shell-maintained variable.
As for $UID being read-only, that's a bashism. There's nothing inherent
about $UID that makes it read-only.
In a POSIX shell, you get this:
$ ksh --version
version sh (ATT Research) 1993-12-28 s+
$ echo $UID $USER
501 jani
$ USER=root
$ UID=1000
$ echo $UID $USER
1000 root
csh is no different:
j...@krakas ~ csh
[krakas:~] root% echo $USER
root
[krakas:~] root% set USER=foo
[krakas:~] root% echo $USER
foo
[krakas:~] root% echo $UID
501
[krakas:~] root% set UID=1000
[krakas:~] root% echo $UID
1000
bash in POSIX mode agrees:
j...@krakas ~ bash --posix
j...@krakas ~ echo $UID
501
j...@krakas ~ UID=1000
j...@krakas ~ echo $UID
1000
Even Perl 5 lets me change it:
j...@krakas ~ perl --version|grep v5
This is perl, v5.8.9 built for darwin-2level
j...@krakas ~ perl -e 'print $ENV{UID}\n; $ENV{UID}=1000; print
$ENV{UID}\n;'
501
1000
--
Jan
Re: $*CWD and chdir()
2009/8/19 Timothy S. Nelson wayl...@wayland.id.au: Ok, so suppose we only allowed direct assignment to absolute paths? That would be currently how it works. -- Carlin
Re: Filename literals
Leon Timmermans wrote: Reading this discussion, I'm getting the feeling that filename literals are increasingly getting magical, something that I don't think is a good development. [...]. I don't want to deal with Windows' strange restrictions on characters when I'm working on Linux. I don't want to deal with any other platform's particularities either. I'd like to agree, and also suggest that the use-case for filename literals probably favors the native approach. Most applications should not hard-code filename constants: they should use config files, ask users, or programatically construct them from other information. OTOH, one-liners and throw-away scripts will frequently hard code these things. So the filename literal syntax should optimize for this usage: a 90% solution that makes easy things trivial (but requires hard things to use an IO CTOR) seems to me to be what I'd want for a one-liner.
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
I don't think python is the only one with that problem, try saving a file with
non utf8 chars in subversion and see what happens.
We should be liberal in what we accept and strict in what we send as we really
don't know the filesystem will return to us. I guess a file read from the
filesystem could have PathBinary as it's default object type. And the
programmer would have the option of converting it.
But you are right we have the same problem with Perl 5 today:
my $file = readdir $dir;
Should $file have the utf8 flag set if my locale is set to uft8?
or should i have to do a :
my $file = eval { decode(utf8, $file, Encode::FB_CROAK); };
every time i get a filename?
Regards Troels.
On Tue, Aug 18, 2009 at 16:37, Nicholas Clarkn...@ccl4.org wrote:
On Tue, Aug 18, 2009 at 01:10:58PM +0200, Jan Ingvoldstad wrote:
On Tue, Aug 18, 2009 at 12:54 PM, Troels Liebe Bentsent...@rapanden.dk
wrote:
Besides that, a simple check on Unix for what the locale is set to might
also be
nice, so we don't write UTF8 files on a filesystem where the rest for the
files
are in Latin1.
The locale doesn't say what format the filenames are on the
filesystem, though, merely the current user's language preferences may
be.
We don't want to make the same mistakes as Python 3:
http://mail.python.org/pipermail/python-dev/2008-December/083856.html
The summary is that different file names in the same directory might be
in different encodings, and your programming language runtime sucks big time
if it doesn't offer you a way to iterate over all of them somehow, even if
you can't render their names.
[Consider a security critical program scanning using glob('*'), which gives
a clean bill of health because it opened all files and found no problems.]
I don't know how Python 3 resolved this.
Nicholas Clark
Re: $*CWD and chdir()
On Tue, Aug 18, 2009 at 10:37 AM, Jan Ingvoldstadfrett...@gmail.com wrote:
It's not that unreasonable.
I disagree, and I think I've explained why, and perhaps we won't get much
further.
I'm not claiming that it's a good idea for bash to adopt this
behavior, only that it's a reasonable expectation tohave upon
encountering the read behavior of $PWD.
Its not unlike, say, applying an UPDATE to a view in an RDBMS: it
seems like it should work. It might not, for various reasons, but
it's not an unreasonable expectation. And in many versions of SQL it
does work for the simpler view/table relationships.
But USER isn't even a shell-maintained variable.
I'm not sure what you mean by a shell-maintained variable.
I mean, it's not a parameter that is ever set by the shell. Unlike
PWD, RANDOM, LINENO, PPID, etc. which are set by the shell.
As for $UID being read-only, that's a bashism. There's nothing inherent
about $UID that makes it read-only.
Huh? I thought UID was a bashism. In my copies of ksh, it's not even
set - ATT ksh93 (version M 1993-12-28 s+ under UWIN, Version JM 93t+
2009-05-01
on Linux) and pdksh 5.2.14. . If it's POSIX, it must be a a
relatively recent addition.
In a POSIX shell, you get this:
$ ksh --version
version sh (ATT Research) 1993-12-28 s+
$ echo $UID $USER
501 jani
Not here.
bash in POSIX mode agrees:
What version of bash? bash-3.2:
$ bash --posix
bash-3.2$ echo $UID
1024
bash-3.2$ UID=500
bash: UID: readonly variable
Did you maybe export UID, so it's being inherited by these subshells?
Even Perl 5 lets me change it:
OK, you clearly exported UID. It's not exported by default, so
$ENV{UID} in Perl should be unset. Try your experiments without
exporting UID.
In any case, %ENV isn't readonly in Perl. But neither are the contents
of %ENV managed by Perl - just inherited from the parent process.
--
Mark J. Reed markjr...@gmail.com
Parrot 1.5.0 TEH PARROTZ! Released!
On behalf of the Parrot team, I'm proud to announce Parrot 1.5.0 TEH PARROTZ!. Parrot (http://parrot.org/) is a virtual machine aimed at running all dynamic languages. Parrot 1.5.0 is available on Parrot's FTP site, or follow the download instructions at http://parrot.org/download. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion on the source code repository to get the latest and best Parrot code. Parrot 1.5.0 News: - Core + Removed several deprecated functions and features + Removed bsr, jsr, branch_cs, and ret opcodes + Removed global stacks system + Changed OPS file format to include explicit preamble + Changed all new 'Iterator' instructions into 'iter' instructions + Removed Configure.pl options for specifying non-working GC cores + Removed unexecuting code as found by Coverity + Improvements to the Parrot Debugger + Added experimental fixed-size structure allocator to the GC + Added experimental lazy arena allocation to the GC + Removed the defunct PASM1 compiler object + Refactored hashes, keys, and iterators + Added corevm make target to build Parrot without all the supporting libraries + Removed Random PMC type and added in a rand dynop + Optimization and Improvements to the NCI thunk generator + New include file libpaths.pasm - Compilers + Multiple .local with same name and different type is now an error on IMCC. - Platforms + Improved support for detecting Fink and Macports + Updated search directories for libraries - Documentation + Parrot Developers Guide: PIR released to publisher and available to purchase + Improved documentation about Parrot Debugger + Update PGE Documentation - Miscellaneous + Added tests + Fixes to code, documentation, and standards Many thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next scheduled release is 15 September 2009. Enjoy! --Andrew Whitworth
r28024 - docs/Perl6/Spec/S32-setting-library
Author: lwall
Date: 2009-08-19 02:08:06 +0200 (Wed, 19 Aug 2009)
New Revision: 28024
Modified:
docs/Perl6/Spec/S32-setting-library/IO.pod
Log:
[IO.pod] fix bogon-infested named parameter syntax
Modified: docs/Perl6/Spec/S32-setting-library/IO.pod
===
--- docs/Perl6/Spec/S32-setting-library/IO.pod 2009-08-18 22:33:22 UTC (rev
28023)
+++ docs/Perl6/Spec/S32-setting-library/IO.pod 2009-08-19 00:08:06 UTC (rev
28024)
@@ -22,8 +22,8 @@
Created: 19 Feb 2009 extracted from S29-functions.pod; added stuff from
S16-IO later
-Last Modified: 20 Apr 2009
-Version: 6
+Last Modified: 18 Aug 2009
+Version: 7
The document is a draft.
@@ -43,11 +43,11 @@
Xopen
multi open (Str $name,
-Bool $:rw = False,
-Bool $:bin = False,
-Str $:enc = Unicode,
-Any $:nl = \n,
-Bool $:chomp = True,
+Bool :$rw = False,
+Bool :$bin = False,
+Str :$enc = Unicode,
+Any :$nl = \n,
+Bool :$chomp = True,
...
-- IO
) is export
@@ -258,8 +258,8 @@
=item new()
method new(
-Bool $:NoOpen,
-Bool $:Blocking,
+Bool :$NoOpen,
+Bool :$Blocking,
-- IO::Streamable
) {...}
@@ -497,7 +497,7 @@
=item new
method new(
-$:Listener, # initialises $.Listener
+:$Listener, # initialises $.Listener
)
The initial value of the $.Listener attribute is defined according to the
following rules:
@@ -579,11 +579,11 @@
=item new
method new(
-Path $:Path,
-$:fd
-Bool $:NoOpen,
-$:Writeable,
-$:Readable
+Path :$Path,
+:$fd
+Bool :$NoOpen,
+:$Writeable,
+:$Readable
);
The CPath and Cfd options are mutually exclusive.
@@ -630,7 +630,7 @@
=item open
$dir.open(
-Str $:enc = Unicode,
+Str :$enc = Unicode,
);
Opens a directory for processing, if the Cnew method was passed the
CNoOpen option.
@@ -714,28 +714,28 @@
This is called automatically on object creation.
method new(
-Str $:Path,
-Array of Str @:PathElements,
+Str :$Path,
+Array of Str :@PathElements,
-Array of Str $:Constraints,
-Str $:Protocol,
+Array of Str :$Constraints,
+Str :$Protocol,
-Str $:Target,
-Str $:LinkType,
+Str :$Target,
+Str :$LinkType,
);
Path and PathElements are mutually exclusive.
-$:Constraints determines whether the $:Path and $:Target strings should be
+$Constraints determines whether the $Path and $Target strings should be
assumed to be Unix-style, Windows-style, or something else.
The Path.Type attribute is initialised as follows:
ValueCondition
==
-Directory$:Path ends in a separator (ie. /)
-Link $:Target is specified
-Other$:Protocol is specified
+Directory$Path ends in a separator (ie. /)
+Link $Target is specified
+Other$Protocol is specified
UndefinedAll other cases
If the $.Type attribute is read, but is still undefined, then an attempt is
@@ -793,16 +793,16 @@
Xmkdir Xmd Xdirectory, create Xtouch
method create(
-Bool $:Recursive,
-Bool $:Truncate,
+Bool :$Recursive,
+Bool :$Truncate,
)
Creates/touches the specified path. In the case of a link or a directory, no
parameters are required. If a file doesn't exist, then no parameters are
required. If the path already exists, then an exception is thrown, unless
-the file is an ordinary file or a link, and $:Truncate is true.
+the file is an ordinary file or a link, and $Truncate is true.
-The $:Recursive option specifies that any necessary parent directories should
+The $Recursive option specifies that any necessary parent directories should
also be created.
=item touch
@@ -813,7 +813,7 @@
Xrmdir Xrd Xdirectory, remove
-method delete(Bool $:Recursive -- Int);
+method delete(Bool :$Recursive -- Int);
This deletes the CPath from the filesystem. If the node has children, it
throws an error unless the CRecursive option is specified. It returns the
@@ -823,19 +823,19 @@
method lines ($handle:
Any $limit = *,
-Bool $:bin = False,
-Str $:enc = Unicode,
-Any $:nl = \n,
-Bool $:chomp = True,
+Bool :$bin = False,
+Str :$enc = Unicode,
+Any :$nl = \n,
+Bool :$chomp = True,
-- List
) is export
multi lines (Str $filename,
Any $limit = *,
-Bool $:bin = False,
-Str $:enc = Unicode,
-Any $:nl = \n,
-Bool $:chomp = True,
+Bool :$bin = False,
+Str :$enc = Unicode,
+Any :$nl = \n,
+Bool :$chomp = True,
-- List
)
Re: $*CWD and chdir()
Ok, here's a fairly significant point posted on IRC.
TimToady wayland76: the point of using $*CWD would be (and would *have* to
be, given how context vars work) to give each thread its own working
directory, independent of the process as a whole
Now, given that chdir is an OS concept that applies to the process as
a whole, rather than individual threads, but $*CWD is designed for individual
threads, that pretty much means that it is a really bad idea to have $*CWD do
chdir() for us.
Now, having said that, I think the idea of a per-thread CWD is a great
idea, and I'd be in favour of using $*CWD over whatever getcwd retrns in Perl6
as much as possible. So I think it would be cool if all relative paths
specified via p{} were relative to $*CWD, not getcwd(). So something like
this:
chdir(/usr/bin);
$*CWD = /home/username;
$path = p{Music};
say $path.canonpath();
# prints /home/username/Music
My question is, what else uses chdir/getcwd style paths? I know
qqx/$cmd @args[]/
...will pass its current dir to the child. Maybe we could have Perl6
do something like this pseudocode under the hood when someone does a qqx.
olddir = getcwd();
chdir($*CWD);
exec(qqx string here);
chdir(olddir);
That would mean that $*CWD would effectively act as a per-thread
working directory.
No doubt someone will write in and tell me how bad an idea this is. I
look forward to having my ignorance exposed :).
-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am |
-
BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-
-END GEEK CODE BLOCK-
Last IO discussion
See this link. http://archive.netbsd.se/?ml=perl6-languagea=2008-11t=9170058 In particular, I thought Tom Christiansen's long message had some relevant info about filename literals. :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
r28026 - in docs/Perl6/Spec: . S32-setting-library
Author: wayland
Date: 2009-08-19 03:57:49 +0200 (Wed, 19 Aug 2009)
New Revision: 28026
Modified:
docs/Perl6/Spec/S16-io.pod
docs/Perl6/Spec/S32-setting-library/IO.pod
Log:
[S32/IO] put in canonpath and realpath, as promised
[S16] Things including:
* Made defaults more sensible (lax vs. strict mode)
* Added use path pragma
* Added :local, :modern, :portable, and :posix
Modified: docs/Perl6/Spec/S16-io.pod
===
--- docs/Perl6/Spec/S16-io.pod 2009-08-19 00:26:55 UTC (rev 28025)
+++ docs/Perl6/Spec/S16-io.pod 2009-08-19 01:57:49 UTC (rev 28026)
@@ -101,9 +101,23 @@
operator. Most of these are filesystem-specific. They confine what can be
included in a filename.
+Any path that starts with a / is considered an absolute path, otherwise
+the path is considered relative.
+
=head3 Default constraints
-The default paths are portable POSIX paths (see POSIX.1-2008 sections
+The default constraints can be set with the use path pragma, for example:
+
+use path :posix;
+use path :modern;
+use path :local;
+
+The default when in strict mode is use path :posix, whereas the default in
+lax mode is use path :local.
+
+=head3 :posix constraints
+
+The :modern set of constraints paths are portable POSIX paths (see
POSIX.1-2008 sections
4.7 and 3.276). If platform/filesystem specific behavior is needed,
specific constraints should be applied as needed (see below).
@@ -114,8 +128,26 @@
Any path that starts with a / is considered an absolute path, otherwise
the path is considered relative.
-=head3 Windows-style constraints
+=head3 :portable
+In addition to the POSIX constraints above, the path should fit into 8
+characters, followed by a full stop, and then three more characters. Only
+the one full stop should appear in the filename. Additionally, no path
+may be longer than 64 characters.
+
+=head3 :local
+
+This is :win on a Windows platform, :unix on a Unix platform, etc. Note
+that this is specifically not portable between platforms with different
+constraint sets.
+
+=head3 :modern constraints
+
+The :modern set of constraints are the same as :posix, except that they
+may contain any UTF-8 character, rather than just those listed.
+
+=head3 :win constraints
+
We allow Windows style paths so converting and maintaining code on this
platform is not a pain.
@@ -124,7 +156,7 @@
Note that this specifically excludes the backslash quoting usually used with
q{}.
-=head3 Unix-style constraints
+=head3 :unix constraints
For Unix specific behavior we have a p:unix{} literal. Here the only
limits are what is defined by the locale and the filesystem type. So we won't
@@ -132,7 +164,9 @@
my Path $path = p:unix{/usr/src/bla/myfile?:%.file};
-And for cases where this is a problem p:bin{} can be used as no checking is
+=head3 :bin constraints (no constraints at all)
+
+If the above are causing problems, p:bin{} can be used as no checking is
done here, other than assuming that / is the separator.
=head3 Other constraints
Modified: docs/Perl6/Spec/S32-setting-library/IO.pod
===
--- docs/Perl6/Spec/S32-setting-library/IO.pod 2009-08-19 00:26:55 UTC (rev
28025)
+++ docs/Perl6/Spec/S32-setting-library/IO.pod 2009-08-19 01:57:49 UTC (rev
28026)
@@ -769,17 +769,24 @@
Returns @.elements concatenated together for use as a string. Usually this
is the path that it was originally created with.
+=item canonpath
+
+method canonpath( -- Str);
+
+No physical check on the filesystem, but a logical cleanup of a path.
+
=item realpath
method realpath( -- Str);
Gets the real path to the object, resolving softlinks/shortcuts, etc
-=item realisepath
+=item resolvepath
-method realisepath();
+method resolvepath(Array of Str @:Types -- Str);
-Changes the Path object to point at whatever is returned by C.realpath().
+...@types can contain real and canon, in any order, and the
+method will run realpath and canonpath in the order specified.
=item ACCEPTS
Re: $*CWD and chdir()
The OS-level chdir() and getcwd() are not thread-safe. The usual
advice is to ignore them completely in multithreaded programs, in
favor of absolute paths (or relative paths from a fixed location,
never calling chdir()). This is part of the a reason that Apache2
recommends fastcgi for non-prefork MPMs (since the CGI spec requires
cgi scripts to start with getcwd() set to the directory containing
them).
Since qqx has to fork a new process anyway, having it chdir(*CWD)
is not a big deal - as long as it's the child, not the parent, that
calls chdir(). But any process with multiple threads should generally
avoid calling chdir() ever.
All of this is assuming that P6's chdir() just calls the OS routine,
of course. It could be made fancier and handle the thread-stuff
itself...
On 8/18/09, Timothy S. Nelson wayl...@wayland.id.au wrote:
Ok, here's a fairly significant point posted on IRC.
TimToady wayland76: the point of using $*CWD would be (and would *have*
to
be, given how context vars work) to give each thread its own working
directory, independent of the process as a whole
Now, given that chdir is an OS concept that applies to the process as
a whole, rather than individual threads, but $*CWD is designed for
individual
threads, that pretty much means that it is a really bad idea to have $*CWD
do
chdir() for us.
Now, having said that, I think the idea of a per-thread CWD is a great
idea, and I'd be in favour of using $*CWD over whatever getcwd retrns in
Perl6
as much as possible. So I think it would be cool if all relative paths
specified via p{} were relative to $*CWD, not getcwd(). So something like
this:
chdir(/usr/bin);
$*CWD = /home/username;
$path = p{Music};
say $path.canonpath();
# prints /home/username/Music
My question is, what else uses chdir/getcwd style paths? I know
qqx/$cmd @args[]/
...will pass its current dir to the child. Maybe we could have Perl6
do something like this pseudocode under the hood when someone does a qqx.
olddir = getcwd();
chdir($*CWD);
exec(qqx string here);
chdir(olddir);
That would mean that $*CWD would effectively act as a per-thread
working directory.
No doubt someone will write in and tell me how bad an idea this is. I
look forward to having my ignorance exposed :).
-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am |
-
BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y-
-END GEEK CODE BLOCK-
--
Sent from my mobile device
Mark J. Reed markjr...@gmail.com
Re: $*CWD and chdir()
On Tue, Aug 18, 2009 at 7:03 PM, Mark J. Reedmarkjr...@gmail.com wrote: The OS-level chdir() and getcwd() are not thread-safe. The usual advice is to ignore them completely in multithreaded programs, in favor of absolute paths (or relative paths from a fixed location, never calling chdir()). This is part of the a reason that Apache2 recommends fastcgi for non-prefork MPMs (since the CGI spec requires cgi scripts to start with getcwd() set to the directory containing them). I like Timothy's suggestion: do not associate $*CWD with chdir at all, but tie $*CWD in with every standard routine that makes use of the current working directory concept. Keep chdir around, but add a note saying that its use should be avoided in favor of assigning to $*CWD. Ditto with getcwd and reading the value of $*CWD. The only thing that gets clobbered by this is the inability to use relative paths when changing the current working directory. Personally, I have no problem with the idea that $*CWD is a magical Path that resolves itself into an absolute Path when you assign a relative Path to it (that is, $*CWD = ($path.relative ?? $*CWD ~ $path :: $path).resolvepath, or something to that effect) - and thus is always an absolute Path; but I can understand that others have a problem with this. On a similar note, I wouldn't mind a bit of magic that has $*CWD test for the existence of the new value before actually making the change, and throwing an exception if the target is not a directory; that way, you're guaranteed that $*CWD is always a valid Path. With this magic in place, I would never be tempted to use chdir or getcwd. Alternatively, $*CWD should be readonly and have a chdir method that implements the above behavior, emulating the features of the OS's chdir in a thread-safe manner. Or just warn people _not_ to alter $*CWD directly, and change chdir and getcwd so that they alter and read $*CWD appropriately by default, and only perform their OS equivalents if you explicitly ask them to. -- Jonathan Dataweaver Lang
