Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


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

Re: Broken backquote behavior in bash?



 Scripts in /etc/profile.d are supposed to be shell-agnostic. 

In any case, it turned out the behavior was more complicated, and specifically 
affects users that are defined in LDAP and not in /etc/passwd. The problem 
does not occur for root or for locally defined users. 

Other symptoms include pipes not working ("ls | more" exits immediately 
with no output), backgrounding fails ("foo &" returns "[1]+  Broken 
pipe  foo"). 



On Fri, Jul 25, 2008 at 7:39 AM, Jerry Feldman <[hidden email]> wrote: 
> Just one comment, the preferred Bash construct is to use $() rather 
> than backquotes. 
> $(/usr/bin/id -u) 
> 
> Try changing to: 
> if [ $(/usr/bin/id -u) = "0 "] 
> if [$(/usr/bin/id -u) -eq 0 ] 
> 
> Note that the -eq is for numeric comparisons. 
> 
> On Thu, 24 Jul 2008 10:50:34 -0400 
> "John Abreau" <[hidden email]> wrote: 
> 
>> I've got a server that's been giving strange errors lately. Most 
>> noticeably, when I login, 
>> I get several errors of the form 
>> 
>>     -bash: [: =: unary operator expected 
>> 
>> I've traced these to files under /etc/profile.d, and on further 
>> testing I find that the 
>> offending lines are using backquotes, e.g. 
>> 
>>         if [ `/usr/bin/id -u` = 0 ] ; then 
>> 
>> When I try to use backquotes on the command line on this server, I get 
>> no output. 
>> Even stranger, if I have a suspended vi job, then running something in 
>> backquotes 
>> terminates the vi process: 
>> 
>>     $ vi foo 
>>     ^Z 
>>     [1]+  Stopped                 nvi foo 
>>     $ echo `echo bar` 
>> 
>>     [1]+  Terminated              nvi foo 
>> 
>> If I do this on my other systems, I get 
>> 
>>     $ echo `echo bar` 
>>     bar 
>> 
>> and the vi job does not terminate. 
>> 
>> I've tried googling for these symptoms, but so far I haven't found a match. 
>> Has anyone else run across this odd behavior? What could be causing it? 
>> 
>> 
>> 
>> -- 
>> John Abreau / Executive Director, Boston Linux &amp; Unix 
>> GnuPG KeyID: 0xD5C7B5D9 / Email: [hidden email] 
>> GnuPG FP: 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99 
>> 
>> -- 
>> This message has been scanned for viruses and 
>> dangerous content by MailScanner, and is 
>> believed to be clean. 
>> 
>> _______________________________________________ 
>> Discuss mailing list 
>> [hidden email] 
>> http://lists.blu.org/mailman/listinfo/discuss
>> 
> 
> 
> 
> 
> -- 
> -- 
> Jerry Feldman <[hidden email]> 
> Boston Linux and Unix 
> PGP key id: 537C5846 
> PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846 
> 
> _______________________________________________ 
> Discuss mailing list 
> [hidden email] 
> http://lists.blu.org/mailman/listinfo/discuss
> 
> 


BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org