Re: Bug#490605: debian-policy: please discourage the usage of echo -n, and echo in general
Manoj Srivastava wrote:
> On Thu, Jun 04 2009, Giacomo Catenazzi wrote:
>
>> I think we could forbid "echo -n" on maintainer and other scripts, but
>> allow it on init.d scripts. Rationale:
>> - portability is more important on other scripts, and it is also not so
>> frequent to use echo -n
>> - init.d are system scripts which special requirement, so they are not
>> portable. And we could ev. workaround with a special alias/path
>> which set a non-portable echo. This is also simple because
>> init.d scripts sould be called only by/via few programs/
>
> I am kinda missing the rationale for the policy change here. At
> this point, forbidding it in one palce and not the other would not make
> life any easier for shells that want to be in /etc/shells, and making a
> policy change seems mostly random churn to me. Yes, echo -n maybehave
> differently in different shells, and it is undefined in POSIX, perhaps,
> but all shells in Debian have a specific interpretation of -n that all
> scripts may rely on.
Yes, You are right. On programs (i.e. in PATH) I think portability is
more important (and within POSIX domain), but init.d script have
a more controllable environment. But I agree, it is not good to
distinguish cases.
> Is there a compelling reason to change policy? If so, what is
> it? From the report, it seems like more of a dev-ref thing;
> recommending some practice is better than others "for portability". I
> am not seeing yet why this belongs in policy and not dev-ref.
I agree. I don't like the change "echo -n" to "printf", I don't think
it is the right thing to do. I think also in this case we must do
standardization from common use. So recommending more "portable"
scripts in dev-ref is good.
I really thing that if policy will do something in this field, will
be mandating the use of common helpers (lsb, possibly colored, ...),
but before we (DD, DM, ...) must have a proven common base.
>
>>> Yes, printf.
>> It is not an alternative:
>> - It is ugly
>
> This is mostly irrelevant. If it is technically superior, it
> would not matter if it offends your sense of aesthetics; it might not
> offend other people.
Technically you are right, but more I see in other standard bodies,
the more I see that aesthetic is a *must* for standard. Standards
are void if nobody use them. As I see the most ugly standards are
also the less used. The most ugly part of existing standards are
also the less used, also if they are technically superior (C99
suffered from this).
So a solution should be aesthetically and technically good, to
"force" users to change code.
For this reason I think helper functions will be the right
things: they have more functionality (allowing to skip parts,
colour for young users), but easy to use and to read.
[But they will never follow actual LSB. In this field it was silly
(return codes, names, ...)]
>
>> - it is not on root partition
>
> Point.
>
>> The ugly part it is IMHO the most important part. Most of people
>> understand "echo -n", but I don't know if all people understand fully
>> printf. Mixing echo and printf is ugly.
>
> People who can't learn something as simple as printf should not
> be allowed to write maintainer scripts or init scripts.
I think they "can't learn", but it different to: "they use correctly"
or simply "they will use it".
Someone told the printf is common in some languages (C, shell, python,...),
but this is also a disadvantage: there are subtle (and also not so subtle)
differences, which port to bugs and misunderstandings.
Unfortunately not all developers are always good developers, which
check carefully code with the right manuals easy accessible.
A good point of new C standardization effort: to try to avoid at
language/compiler level security errors from lazy coders.
ciao
cate
>
>
> manoj
Reply to: