RFC: use readable $(cmd) syntax instead of unreadable `cmd`

[Jari Aalto]

The following message is a courtesy copy of an article
that has been posted to gmane.linux.debian.devel.general as well.


FOREWORD

I have seen following construct to be used in shell-context
(makefiles, sh-scripts, Perl):

  `cmd` [1]

However, the POSIX standard and SUSv[23] declares alternative way of
accomplishing the same with in *sh context:

  $(cmd) [2]

I would see following problems quality wise with [1]:

- The backtick version is not easily readable in high resolution screens
  or in terminals with small fonts 

- There may be problems in distinguishing character ' from ` with sme
  particularly selected font.

- The missing backtick is hard to find in highly quoted context, where
  single, double quotes and backticks play the code tune.

- The backtick is awkwardly located in some keyboards. (possible
  orphan/adopt/NMU maintenance problem)

- Lastly, isually impaired people have problems with non-easily
  dintinguishable content. ' and ` fall into this category.

All Debian *sh compatible shells support $() and are thus POSIX/SUS
compliant in this respect. 

BUG REPORTS -- AND REPONSES

I have reported bugs against backtick and suggested to change to use
the more readable alternative. The result was surprising. To quote
one message (bug closed reasoning):

 "If your development environment cannot display ` differently than ' ,
 you need to get a new one."

I'm askinf if it is ok to to reopen such bugs based of better QA
aspects. Possibly by providing patches if the maintainer is busy
elsewhere to handle such a "minor issue" from his perspective.

Jari

REFERENCES

The Single UNIX Specification, Version 2 (SUSv2):
"Shell Command Language"


...The input characters within the quoted string that are
also enclosed between "$(" and the matching ")" will not
be affected by the double-quotes, but rather define that
command whose output replaces the $(...)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: use readable $(cmd) syntax instead of unreadable `cmd`

[Marco d'Itri]

On Feb 09, Jari Aalto <[EMAIL PROTECTED]> wrote:

> I have reported bugs against backtick and suggested to change to use
> the more readable alternative. The result was surprising. To quote
> one message (bug closed reasoning):
> 
>  "If your development environment cannot display ` differently than ' ,
>  you need to get a new one."
Reasonable answer.

> I'm askinf if it is ok to to reopen such bugs based of better QA
> aspects. Possibly by providing patches if the maintainer is busy
> elsewhere to handle such a "minor issue" from his perspective.
No, it's not. Even if a patch is provided, handling a bug is a time
consuming activity (*horribly* time consuming if the patch is for
upstream code).
If you really think this crusade is worth being pursued then I suggest
you just mail patches to Debian maintainers for original scripts and to
the upstream maintainers for the rest.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: RFC: use readable $(cmd) syntax instead of unreadable `cmd`

[Russ Allbery]

Jari Aalto <[EMAIL PROTECTED]> writes:

> I have reported bugs against backtick and suggested to change to use the
> more readable alternative. The result was surprising. To quote one
> message (bug closed reasoning):

>  "If your development environment cannot display ` differently than ' ,
>  you need to get a new one."

> I'm askinf if it is ok to to reopen such bugs based of better QA
> aspects. Possibly by providing patches if the maintainer is busy
> elsewhere to handle such a "minor issue" from his perspective.

I have to admit that I agree with that response.

For one thing, $() has had some odd behavior and odd bugs, or has not been
supported, with some old shells.  Personally, I prefer to use one and only
one shell script coding style that I know is portable rather than adopting
new shell features (most longer programs are better written in something
other than shell anyway, IMO, for maintainability).

For another, `` is more widely recognized I think, and therefore more
readable to the average developer, than $(), which looks like another of
the many [EMAIL PROTECTED] line-noise shell variable expansion syntaxes 
supported by
some shells.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: use readable $(cmd) syntax instead of unreadable `cmd`

[John Goerzen]

On Fri, Feb 09, 2007 at 07:26:21PM +0100, Marco d'Itri wrote:
> > I'm askinf if it is ok to to reopen such bugs based of better QA
> > aspects. Possibly by providing patches if the maintainer is busy
> > elsewhere to handle such a "minor issue" from his perspective.
> No, it's not. Even if a patch is provided, handling a bug is a time
> consuming activity (*horribly* time consuming if the patch is for
> upstream code).
> If you really think this crusade is worth being pursued then I suggest
> you just mail patches to Debian maintainers for original scripts and to
> the upstream maintainers for the rest.

I agree.  And I would add that this is not a bug (not a defect, etc) at
all.  It is perfectly valid syntax.  If you're going to open up bugs on
this, then you might as well file a bug against the kernel for not
indenting like GNU does, against libc for not indenting like Linus does,
and against gnome for not indenting like either of them do.  

-- John


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: use readable $(cmd) syntax instead of unreadable `cmd`

[Kapil Hari Paranjape]

Hello,

On Fri, 09 Feb 2007, Jari Aalto wrote:
> The following message is a courtesy copy of an article
> that has been posted to gmane.linux.debian.devel.general as well.



> BUG REPORTS -- AND REPONSES
> 
> I have reported bugs against backtick and suggested to change to use
> the more readable alternative. The result was surprising. To quote
> one message (bug closed reasoning):
> 
>  "If your development environment cannot display ` differently than ' ,
>  you need to get a new one."
> 
> I'm askinf if it is ok to to reopen such bugs based of better QA
> aspects. Possibly by providing patches if the maintainer is busy
> elsewhere to handle such a "minor issue" from his perspective.

I think most maintainers would consider this a "minor" bug for the
following reasons:
1. The backtick may already be in upstream code and the
"minority" of a bug report exponentiates as it travels up
the stream :-)
2. The scripts are usually managed by a much smaller
number of people than those that use them. This means that
those who need to spot the difference between "'" and "`"
is small.
3. It would require a lot of effort to hunt down and fix
all such instances down in all code in the Debian archive.
One of the reasons is that the backtick and other "symmetric"
quotations marks are harder to locate by pattern searches.

However, I believe that if you provide the patch then you have at
least eliminated (3) and made it likelier that (1) can be handled
as well.

Regards,

Kapil.
--



signature.asc
Description: Digital signature

Re: RFC: use readable $(cmd) syntax instead of unreadable `cmd`

[Joey Hess]

Jari Aalto wrote:
>  "If your development environment cannot display ` differently than ' ,
>  you need to get a new one."

Note that even though I wrote the above, I'm not exactly opposed to $().
I've been using $() in most shell code I write for years. But this does
not mean that I feel it's worth my time to go back and change every
instance of backquotes in all the code I wrote before that, or all the
code from upstream in all my packages. Doing so is too high a level of
busy-work.

The fact that in a makefile or rules file you have to write $$() (or
$(shell ) though that's not exactly the same), also makes backquotes a
more appealing option in makefiles. Similarly, while perl does allow
writing qx{} instead of using backquotes, that's sufficiently uglier
that I still tend to use backquotes there.

The primary benefit of $() is not readability anyway, it's easier
nesting. Nested backquotes in shell are really ugly.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: RFC: use readable $(cmd) syntax instead of unreadable `cmd`

[J.A. Bezemer]

On Fri, 9 Feb 2007, Jari Aalto wrote:

> FOREWORD
> 
> I have seen following construct to be used in shell-context
> (makefiles, sh-scripts, Perl):
> 
>   `cmd` [1]
> 
> However, the POSIX standard and SUSv[23] declares alternative way of
> accomplishing the same with in *sh context:
> 
>   $(cmd) [2]

[..]
> All Debian *sh compatible shells support $() and are thus POSIX/SUS
> compliant in this respect. 

[..]
> The Single UNIX Specification, Version 2 (SUSv2):
> "Shell Command Language"
> 
> 
> ...The input characters within the quoted string that are
> also enclosed between "$(" and the matching ")" will not
> be affected by the double-quotes, but rather define that
> command whose output replaces the $(...)

Your mail makes it sound like $( ) is the only command substitution
allowed by POSIX/SUSv[23]. It is not. Let me quote the _really_ relevant
section of SUSv2,
http://www.opengroup.org/onlinepubs/007908799/xcu/chap2.html#tag_001_006_003
and SUSv3 = POSIX (IEEE1003.1, 2004 Edition),
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_03

Command substitution allows the output of a command to be substituted
in place of the command name itself. Command substitution shall occur
when the command is enclosed as follows:

$(command)

or (backquoted version):

`command`


Further, you didn't yet mention the only disadvantage of backquotes that I
personally find important enough to consider, namely that (multi-level)
nesting quickly gets horrible. So I personally tend to use $( ) only when
nesting.

And exactly that is also the only reason mentioned in the Rationale volume
of SUSv3/POSIX,
http://www.opengroup.org/onlinepubs/009695399/xrat/xcu_chap02.html#tag_02_02_06_03

... Because of these inconsistent behaviors, the backquoted variety of
command substitution is not recommended for new applications __that
nest command substitutions or attempt to embed complex scripts__.

(my underlining.)


Best regards,

  Anne Bezemer


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]