[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

38 and some POSIX news about filenames [Was: Re: 38]

On 27.08.2010 12:29, posion bit wrote:
On Fri, Aug 27, 2010 at 12:13 PM, Josselin Mouette<joss@debian.org>  wrote:
Le vendredi 27 août 2010 à 11:57 +0200, Samuel Thibault a écrit :
Not if I have a "/etc/rc2.d/K03my damn daemon"

Which is again the debian rules and the LSB rules about
naming the init.d scripts.

Debian rules and LSB won't prevent users (even root) from doing that.

And if root types “rm -rf /”, is it a bug in Debian?

If root creates a spaced or hugly chars filename, or some program
creates it, is a bug in Debian ?

I just use to try to code bash, as bash needs to be coded and fix my
problems when they are pointed.

I agree, there is a lot of problems and some wrongly unquoted
variables that are used also in user space.

And as I already said, I like to see improvements in many other cases, just to show users how to code better.

But don't shot to correct (but not-optimal) cases.

BTW non trivial task are nearly impossible to do correctly in bash.

But some good news about filename portability:

* POSIX will forbid changing locales which changes <slash> and <dot>.
So we are safe that a filename could not contain '/' (constructed in
an other (possibly user defined) locale.

* File names will be "character strings" (new concept of filename strings) which is independent to locale. So we could see and access
files also if they contains characters invalid in current locale.
[Debian still have some bugs about this]

* POSIX shell utilities will handle better filename which contain spaces.
E.g. "cmd1 | cmd2", where cmd1 prints filenames. Such cmd1 will have some convention to quote spaces (in an uniform way) to distinguish multiple files from filename with spaces. And cmd2 will support
such quoting convention.
Nearly like our non portable "-0", but I think in a more visible
(on console) way.

PS: These are intents for next corrigenda, I don't garantee all features will be in POSIX and surely not how I described it ;-)
And Linux + glibc could handle it differently.


Reply to: