zben@umd5.UUCP (Ben Cranston) (06/18/86)
About a week ago the following shell script was posted to net.jokes: > # encrypt/decrypt a rot13 file > # usage: rot13 file or command | rot13 > eval tr '"[A-Z][a-z]" "[N-Z][A-M][n-z][a-m]"' ${1:+'<$1'} ^ What good is this colon? We were speculating that it might serve to terminate a numeric expression a la ${foo+bar-1:+defalt} but were not able to get this shell script to work until the colon be removed. We also had to remove the [square brackets] for it seems that "tr" on this system not only doesn't need them but treats them as normal characters! On this (BSD) system the following two scripts do seem to work: #! /bin/sh # encrypt/decrypt a rot13 file # usage: rot13 file or command | rot13 eval tr '"A-Za-z" "N-ZA-Mn-za-m"' ${1+'<$1'} #! /bin/sh # encrypt/decrypt a rot13 file # usage: rot13 file or command | rot13 echo tr 'A-Za-z N-ZA-Mn-za-m' ${1+'<$1'} Are there in fact variant unices that require the [square brackets] on "tr" commands and allow integer expressions in ${parm+defalt} lists? Or is this just somebody's idea of a bad joke? -- umd2.UMD.EDU Kingdom of Maryland Sperrows 1100/92 Ben Cranston zben @ umd5.UUCP {seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben umd2.BITNET
guy@sun.UUCP (06/20/86)
> > eval tr '"[A-Z][a-z]" "[N-Z][A-M][n-z][a-m]"' ${1:+'<$1'} > ^ > What good is this colon? We were speculating that it might serve to > terminate a numeric expression a la ${foo+bar-1:+defalt} but were not > able to get this shell script to work until the colon be removed. See previous postings concerning alleged "incompatibility" between 4.2BSD and Sun UNIX 3.0. "${1+'<$1'}" means if "$1" (first parameter to the script) is set (i.e., a parameter was supplied to the script), substitute "<$1", otherwise substitute nothing. Thus, if an argument is supplied, "tr" has its input redirected to the argument supplied, otherwise it reads from the standard input. "${1:+'<$1'}" means if "$1" is set and is non-null, substitute "<$1", otherwise substitute nothing. The ":" is a feature of the S3 and later shells, and isn't in the 4.2BSD shell, which is why it didn't work until you removed it. It's not really necessary. > We also had to remove the [square brackets] for it seems that "tr" on this > system not only doesn't need them but treats them as normal characters! > ... > Are there in fact variant unices that require the [square brackets] > on "tr" commands and allow integer expressions in ${parm+defalt} lists? Yes to the first (for some reason, the S5 and, I think, S3 versions of "tr" require the square brackets) and no to the second (the "1" refers to the first argument, and is not a numeric value). > Or is this just somebody's idea of a bad joke? Unless there was a good reason to incompatibly change the syntax of "tr" from what AT&T's own V7 supported, one could argue that the USDL perpetrated a bad joke on us all by doing so.... -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
henry@utzoo.UUCP (Henry Spencer) (06/25/86)
> Unless there was a good reason to incompatibly change the syntax of "tr" > from what AT&T's own V7 supported, one could argue that the USDL perpetrated > a bad joke on us all by doing so.... Unfortunately, the people to blame for the bad joke are not USDL but the demigods who gave us V7. V6 tr used the square-bracket syntax! The problem is not that USDL made incompatible changes, but that they did not copy incompatible changes made elsewhere. I don't see any easy solution for this mess. -- Usenet(n): AT&T scheme to earn revenue from otherwise-unused Henry Spencer @ U of Toronto Zoology late-night phone capacity. {allegra,ihnp4,decvax,pyramid}!utzoo!henry