Seems like a library
interface that isn't well thought through:
Accepting a number as
input, but it's only reasonably written in one
base. Then it's not
really a number, but rather a formatted string, so
the chmod function
should take a string as argument and do its own
parseInt(_,8) on it
(and accept other formats too, like "a+rw" or
"rwxr--r--").
Don't
try to fix a single broken interface by adding unnecessary
features
to the language!
/L 'not a Unix hater, but probably a chmod hater'
I'll chime in with my vote - I
would LOVE to be able to use octal literals again in GPSEE for setting
file permissions.
chmod("filename", parseInt("777", 8))
^^^^
just looks stupid when chmod("filename", 0777) would work just fine.
Wes
--
Wesley W. Garland
Director,
Product Development
PageMail, Inc.
+1 613 542 2787 x 102
[Resending reply with
elaboration. /be]
Yes, the ability to quote the octal literal with Node's APIs came up
on
the gist, but it's not enough.
Quoting is easy to forget, and making the runtime convert string
(literal) to number is inefficient compared to having JS do it at
compile-time, and making the runtime (even via a call to parseInt) do it
also increases bug habitat ever so slightly.
Mainly, users don't have to shun octal in non-strict mode, and they
do
not in Node code I have seen. They won't be adopting strict mode as far
as I can tell. Banning octal is just one more reason for those who
*might* adopt strict mode to reject it.
Agree on parseInt. Old dog, hard to change (runtime-only errors are
migration- and user-hostile). Not sure what to do there.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
/cc es-discuss (sorry Brendan
-- you always seem to be the target of my reply-all fails)
Sorry, are you seriously
proposing that Node.js users when they specify file permissions should
manually write that out? Come on! Sorry, that's just way too verbose and
ugly.
They don't have to, an
octal string mode works just fine:
fs.chmod(path, "0777")
Octals can be little
hazardous, and not just to noobs, but the hazard isn't with literals,
it's with parseInt:
parseInt("022") // 18
Better
than losing octal literals would be to throw out the unary version of
parseInt. Guessing the radix is crazy! I'm indifferent to whether octals
stay the same or grow a o, but parseInt could really use some love!
