[KSH] grep geeft false positives?

[Cidolfas]

Tijdens het schrijven van een script kwam ik iets merkwaardigs tegen. Als ik zoals in onderstaand code block een pipe gebruik in een exec statement, krijg ik later in het script problemen met grep die soms false positives oplevert:

Bash:

#!/bin/ksh
# 
# Command seems irrelevant, using a pipe in the exec
# results in a false positive on the greps below
#
#echo foo | cut -c $(echo bar | grep bar)   # FAILS
echo foo | grep $(echo bar | sort -u)       # FAILS
#echo foo | grep $(echo bar)            # OK

# Greps
grep foo /etc/passwd  && echo "1: false positive?"
grep foo /etc/passwd  && echo "2: false positive?"
grep foo /etc/passwd  && echo "3: false positive?"

Ik test dit door bovenstaand scriptje met watch uit te voeren: watch -n1 ./test.ksh. Er verschijnt dan random een false positive melding op het scherm, terwijl de returncode van de grep altijd 1 zou moeten zijn

Nu vroeg ik mij af of ik iets vreemds doe, of dat er misschien een bug in de gebruikte ksh versie zit. De gebruikte ksh versie is ksh-20100621-5.el5_8.1 onder RHEL5, ik meen de laatste versie. Onder RHEL6 met ksh versie ksh-20100621-16.el6.x86_64 is dit niet te reproduceren.

Iemand een idee om verder te debuggen?

[Cidolfas]

Helemaal niemand? Misschien verplaatsen naar Non-Windows Operating Systems?

Bash:

[root@server1 ~]# ksh
# /bin/false;echo $?
1
# /bin/false;echo $?
1
# echo foo | grep $(echo foo | grep foo)
foo
# /bin/false;echo $?
0
# 

[MSalters]

Tja, je vraag is wel wat onduidelijk. Test eens met een andere file dan /etc/passwd; die wordt nog wel eens door anderen gebruikt. Een sharing violation zou je al een error code 2 op moeten leveren.

[pedorus]

En wellicht dat het helpt om de eerste k te veranderen in ba als je kennelijk last hebt van bugs in verouderde KSH-versies. Of gewoon updaten in plaats van nog meer tijd hieraan besteden

[Cidolfas]

pedorus schreef op dinsdag 08 januari 2013 @ 22:11:
En wellicht dat het helpt om de eerste k te veranderen in ba als je kennelijk last hebt van bugs in verouderde KSH-versies. Of gewoon updaten in plaats van nog meer tijd hieraan besteden

Dat is natuurlijk geen oplossing. De gebruikte KSH versie is gewoon de laatste versie in RH5.8, een supported versie.

Het veranderen naar bash is wel wenselijk, maar in de praktijk niet haalbaar. Richtlijnen, architectuur...etc..

MSalters schreef op dinsdag 08 januari 2013 @ 22:04:
Tja, je vraag is wel wat onduidelijk. Test eens met een andere file dan /etc/passwd; die wordt nog wel eens door anderen gebruikt. Een sharing violation zou je al een error code 2 op moeten leveren.

Met het tweede voorbeeld probeer ik het wat duidelijker te maken. /bin/false geeft altijd return code 1 terug, de nested pipe in de command substitution veroorzaakt dat de return code van /bin/false 0 is.

[pedorus]

Cidolfas schreef op woensdag 09 januari 2013 @ 08:46:
Dat is natuurlijk geen oplossing. De gebruikte KSH versie is gewoon de laatste versie in RH5.8, een supported versie.

Als je die commando's met false daadwerkelijk zo hebt uitgevoerd, dan bevat deze versie overduidelijk een bug (of heeft iemand het environment verkl**t). Als het daadwerkelijk een gesupporte versie betreft, dan wordt het tijd om naar die support te gaan.

Werkt dit trouwens 100% van de tijd zo?

Het veranderen naar bash is wel wenselijk, maar in de praktijk niet haalbaar. Richtlijnen, architectuur...etc..

Juist ksh is helaas inconsistent over verschillende architecturen. http://stackoverflow.com/questions/74844/bash-or-ksh

Regels zijn er om uitzonderingen te maken toch?

Alternatief is het zodanig anders opschrijven dat je om de bug weet heen te werken. Misschien een onzinnige call of zelfs sleep er tussen gooien als workaround, die de bug opvangt?

[Cidolfas]

pedorus schreef op woensdag 09 januari 2013 @ 09:46:
[...]

Als je die commando's met false daadwerkelijk zo hebt uitgevoerd, dan bevat deze versie overduidelijk een bug (of heeft iemand het environment verkl**t). Als het daadwerkelijk een gesupporte versie betreft, dan wordt het tijd om naar die support te gaan.

Werkt dit trouwens 100% van de tijd zo?


[...]

Juist ksh is helaas inconsistent over verschillende architecturen. http://stackoverflow.com/questions/74844/bash-or-ksh

Regels zijn er om uitzonderingen te maken toch?

Alternatief is het zodanig anders opschrijven dat je om de bug weet heen te werken. Misschien een onzinnige call of zelfs sleep er tussen gooien als workaround, die de bug opvangt?

Het opvragen van de return code van /bin/false na de command substitution gaat niet 100% meteen fout. Als je met meerdere keren probeerd (1 keer de command substitution, daarna meerdere keren /bin/false;echo $?) is de return code random 0 of 1.

Enkeltje support inderdaad...

[NMe]

Cidolfas schreef op dinsdag 08 januari 2013 @ 21:25:
Helemaal niemand? Misschien verplaatsen naar Non-Windows Operating Systems?

Grappig dat je dat zegt. Waar hoort mijn topic?

PRG>>NOS

[CAPSLOCK2000]

Ik heb het getest op een RHEL 5.8 machine en krijg dezelfde (foutieve) resulaten.

[jnr24]

Hier ook, centos 5.8 ksh version sh (AT&T Research) 93t+ 2010-06-21


(ook met backticks en een grep op een /tmp/never_used file die nooit locks, writes of content heeft)

edit:Ubuntu ksh versie 93u-1 heeft het probleem niet

[ Voor 102% gewijzigd door jnr24 op 10-01-2013 09:10 ]

[Cidolfas]

Gelukkig meer mensen met het probleem. Lijkt inderdaad RH specifiek te zijn.