tee|tee|tee
The tee(1) documents fail to say what happens when tee is given no arguments. Do say what is going on in $ echo o|tee|tee|tee o Also there is a Info reference to (bashref), but here on Debian there is no such match in apt-file(1).
Re: expr exit status
What are all the exit statuses I need to check just after expr command? Is it only need to check 1 or 2 or 3 for fail condition and zero for success ?else pease specify You only need to check for non-zero exit codes for failure.
Re: tee|tee|tee
jida...@jidanni.org writes: The tee(1) documents fail to say what happens when tee is given no arguments. Do say what is going on in $ echo o|tee|tee|tee The `tee' command copies standard input to standard output and also to any files given as arguments. it looks quite clear to me, if you don't specify any file then stdin is copied only to stdout. Cheers, Giuseppe
Re: Incorrect use of USE_XATTR in coreutils-8.4
According to Jim Meyering on 1/17/2010 1:03 AM: Thanks! That would fix it, but please retain the 0/1 semantics, in case we ever want to use USE_XATTR in a C (as opposed to cpp) expression. # Map yes,no to 1,0. AC_DEFINE_UNQUOTED([USE_XATTR], [`test $use_xattr = yes echo 1 || echo 0`], [Define if you want extended attribute support.]) OK, committed with that change. -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net signature.asc Description: OpenPGP digital signature
Re: Incorrect use of USE_XATTR in coreutils-8.4
Eric Blake wrote: According to Jim Meyering on 1/17/2010 1:03 AM: Thanks! That would fix it, but please retain the 0/1 semantics, in case we ever want to use USE_XATTR in a C (as opposed to cpp) expression. # Map yes,no to 1,0. AC_DEFINE_UNQUOTED([USE_XATTR], [`test $use_xattr = yes echo 1 || echo 0`], [Define if you want extended attribute support.]) OK, committed with that change. Thank you. I see you shortened it slightly, too: ... [`test $use_xattr != yes; echo $?`], IMHO, that's slightly less readable than the above. I hesitate to quibble too much (it's ok to leave it), since this is .m4 after all, but we should try to keep things accessible, when convenient.
RE: different behavior of sort
Eric: Very interesting. However, it doesn't seem to work, after I followed the instructions of http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Sort-does-not-sort-in-normal-order_0021. At the host that sort doesn't work, where LC_ALL is null, I ran: export LC_ALL=POSIX env |grep LC_ALL LC_ALL=POSIX But sort still doesn't work: sort -n -k2.1,2.4 /tmp/sort.out /dev/emcpowera 47G 39G 7.8G 84% /DB1/DW/data9 /dev/emcpowerb 47G 43G 4.2G 91% /DB1/DW/data10 /dev/emcpowerc 46G 181M 46G 1% /DB1/DW/dwtmp16 /dev/emcpowerh 70G 30G 40G 43% /DB1/DW/data6 /dev/emcpoweri 70G 68G 2.2G 97% /DB1/DW/data7 /dev/emcpowerj 70G 68G 2.1G 97% /DB1/DW/data8 /dev/emcpowerl540G 439G 102G 82% /DB1/DW/data3 /dev/emcpowerm540G 420G 121G 78% /DB1/DW/data5 /dev/emcpowern 23G 14G 9.4G 59% /DB1/DW/data4 /dev/emcpowero540G 509G 32G 95% /DB1/DW/data2 /dev/emcpoweru600G 407G 194G 68% /DB1/DW/data1 /dev/emcpowerw183G 29G 154G 16% /DB1/DW/LOGARCH /dev/emcpowery 92G 188M 92G 1% /DB1/DW/LOGACT === At the other host where sort works, I ran: export LC_ALL=POSIX env |grep LC_ALL LC_ALL=POSIX And sort stopped working: sort -n -k2.1,2.4 /tmp/sort.out /dev/emcpowera 47G 39G 7.8G 84% /DB1/DW/data9 /dev/emcpowerb 47G 43G 4.2G 91% /DB1/DW/data10 /dev/emcpowerc 46G 181M 46G 1% /DB1/DW/dwtmp16 /dev/emcpowerh 70G 30G 40G 43% /DB1/DW/data6 /dev/emcpoweri 70G 68G 2.2G 97% /DB1/DW/data7 /dev/emcpowerj 70G 68G 2.1G 97% /DB1/DW/data8 /dev/emcpowerl540G 439G 102G 82% /DB1/DW/data3 /dev/emcpowerm540G 420G 121G 78% /DB1/DW/data5 /dev/emcpowern 23G 14G 9.4G 59% /DB1/DW/data4 /dev/emcpowero540G 509G 32G 95% /DB1/DW/data2 /dev/emcpoweru600G 407G 194G 68% /DB1/DW/data1 /dev/emcpowerw183G 29G 154G 16% /DB1/DW/LOGARCH /dev/emcpowery 92G 188M 92G 1% /DB1/DW/LOGACT After I set it back to null, which was null originally, sort worked: export LC_ALL= sort -n -k2.1,2.4 /tmp/sort.out /dev/emcpowern 23G 14G 9.4G 59% /DB1/DW/data4 /dev/emcpowerc 46G 181M 46G 1% /DB1/DW/dwtmp16 /dev/emcpowera 47G 39G 7.8G 84% /DB1/DW/data9 /dev/emcpowerb 47G 43G 4.2G 91% /DB1/DW/data10 /dev/emcpowerh 70G 30G 40G 43% /DB1/DW/data6 /dev/emcpoweri 70G 68G 2.2G 97% /DB1/DW/data7 /dev/emcpowerj 70G 68G 2.1G 97% /DB1/DW/data8 /dev/emcpowery 92G 188M 92G 1% /DB1/DW/LOGACT /dev/emcpowerw183G 29G 154G 16% /DB1/DW/LOGARCH /dev/emcpowerl540G 439G 102G 82% /DB1/DW/data3 /dev/emcpowerm540G 420G 121G 78% /DB1/DW/data5 /dev/emcpowero540G 509G 32G 95% /DB1/DW/data2 /dev/emcpoweru600G 407G 194G 68% /DB1/DW/data1 At both hosts, it is LANG=en_US.UTF-8. I've checked several hosts. When sort is 5.2.1, it works. When sort is 5.97, it doesn't work. All hosts have LANG=en_US.UTF-8. Thanks. Have a nice day, Sheila Yao -Original Message- From: Eric Blake [mailto:e...@byu.net] Sent: Monday, January 18, 2010 9:54 PM To: Sheila Yao Cc: bug-coreutils@gnu.org Subject: Re: different behavior of sort According to Sheila Yao on 1/18/2010 12:32 PM: At one box, I've sort version 5.2.1 and sort works correctly. At another box with sort 5.97, it doesn't work correctly. Both of those are quite old. The latest stable version is 8.4. It works correctly for this output: It probably works correctly for both outputs, with the difference boiling down to a difference in your input - namely your locale environment variables. This is a FAQ: http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Sort-does-not-sort-in-normal-order_0021 -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net
Re: different behavior of sort
Sheila Yao s...@secureworks.com writes: sort -n -k2.1,2.4 /tmp/sort.out /dev/emcpowera 47G 39G 7.8G 84% /DB1/DW/data9 The sort key is probably not what you think it is. I have marked it for you. Since the sort key is identical in all lines, sort has used as a last resort the whole line as the sort key. From sort --help: POS is F[.C][OPTS], where F is the field number and C the character position in the field; both are origin 1. If neither -t nor -b is in effect, characters in a field are counted from the beginning of the preceding whitespace. You should probably just use the whole second field as the sort key. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
RE: different behavior of sort
Eric: So it is not a bug? When I use sort -n -k2.1,2.19, it sorts accordingly. Thanks. Have a nice day, Sheila Yao -Original Message- From: Andreas Schwab [mailto:sch...@linux-m68k.org] Sent: Tuesday, January 19, 2010 11:23 AM To: Sheila Yao Cc: Eric Blake; bug-coreutils@gnu.org Subject: Re: different behavior of sort Sheila Yao s...@secureworks.com writes: sort -n -k2.1,2.4 /tmp/sort.out /dev/emcpowera 47G 39G 7.8G 84% /DB1/DW/data9 The sort key is probably not what you think it is. I have marked it for you. Since the sort key is identical in all lines, sort has used as a last resort the whole line as the sort key. From sort --help: POS is F[.C][OPTS], where F is the field number and C the character position in the field; both are origin 1. If neither -t nor -b is in effect, characters in a field are counted from the beginning of the preceding whitespace. You should probably just use the whole second field as the sort key. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: tee|tee|tee
GS == Giuseppe Scrivano gscriv...@gnu.org writes: GS jida...@jidanni.org writes: The tee(1) documents fail to say what happens when tee is given no arguments. Do say what is going on in $ echo o|tee|tee|tee GS The `tee' command copies standard input to standard output and also to GS any files given as arguments. GS it looks quite clear to me, if you don't specify any file then stdin is GS copied only to stdout. OK, then perhaps mention what actions are a no-op... as it all looks mysterious to beginners.
Re: Bug in expr***urgent
On Tue, Jan 19, 2010 at 9:10 PM, Eric Blake e...@byu.net wrote:
According to salih k on 1/16/2010 7:32 AM:
Piece of Script
--
/isnum=`awk -F$delim '$1==BH{print $5}' $fil`/
/
That's still not exactly what you ran (you marked it up afterwards), but
it is close enough, I suppose.
int_num=`echo -e $isnum | cut -f1 -d'.'`
echo -e is not portable. And if all you are trying to do is grab
everything before the first '.', you can do that without even forking:
int_num=${isnum%%.*}
But using a more efficient implementation won't change the net result of
your script, at least on systems where echo -e does what you wanted.
add_num=`expr $int_num + 1 1/dev/null 21`
This line sets add_num to the empty string (because there is no output
from expr). Why run a command substitution if there won't be any output?
Also, your lack of shell quoting could cause you grief; it would be more
robust to use $int_num rather than $int_num. The following is similar
to your above line, but safer:
add_num=
expr $int_num + 1 /dev/null 21
kms=$?
And even more efficiently, you can get the same results without forking,
by following my earlier advice:
case $int_num in
*[!0-9]*) kms=1; echo non-numeric;;
*) kms=0; echo numeric;;
esac
But again, switching to a more efficient implementation shouldn't seem to
have any bearing on your results.
kms=$?
# if [ $? -ne 0 ]
if [ $kms -ne 0 ]
then
log_msg Debug msg4.new1 File has expr pstat $kms int_num is
$int_num
Well, I don't see anything obvious about why you are seeing this:
Debug msg3.1 File FILE1 has int_num1 28 has ps 0
Debug msg4.new1 File has expr pstat 51198 int_num is 28
...
Debug msg3.1 File FILE2 has int_num1 1 has ps 0
then again, you post-formatted the output, too (notice the inconsistent
spacing), and you didn't post the definition of log_msg. So who knows
what else your post-formatting has changed, such that we aren't seeing
EXACTLY what happened to you.
But if it is a bug, then the bug is in your /bin/sh and not in expr. And
if you really do have a buggy shell, then there's nothing this list can do
to help you.
Is it because add_num=`expr $int_num + *1 1/dev*/null 21` whether i
have to chanage it to
add_num=`expr $int_num + *1 */dev/null 21`?
The change between '/dev/null' and '1/dev/null' has no effect - they are
strictly equivalent in shell programming. You may be benefited by doing
more homework on shell programming. But so far, you have failed to show
any evidence of a bug in expr. And inserting spurious * into the lines
doesn't make your example any easier to attempt and reproduce.
--
Don't work too hard, make some time for fun as well!
Eric Blake e...@byu.net
Hi,
Thats fine but I did not got the answer why the exit status shows more than
255 during first run ,
ie exit status is 51198 even though the argument to expr int_num is 28
and in some cases it is 1552 even though the argument to expr int_num is 1.
To show this one i have provided the log
* Debug msg3.1 File FILE1 has int_num1 28 has ps 0
Debug msg4.new1 File has expr pstat 51198 int_num is 28
...
*
* Debug msg3.1 File FILE2 has int_num1 1 has ps 0*
*
function *log_msg
log_msg()
{
echo -e $* | tee -a $LOG
}
LOG=$LOG_DIR
and $BASE/log--afile name from thios i provided the log
So you are saying that this will not happen but this happened that y the
log.What else I can provide.
As a solution am asking whether I can check *if [ $kms -eq 1 -o $kms –eq 2
–o $kms –eq 3 ] *instaed of *if [ $kms -ne 0 ]*
as the mannual says
*info expr|more
Exit status:*
* 0 if the expression is neither null nor 0,
1 if the expression is null or 0,
2 if the expression is syntactically invalid,
3 if an error occurred.*
as the manager is not happy to change the command ( case $int_num in
*[!0-9]*|'') non nume ;;))as this was working in unix and also this issue
happens in rare.we don t think issue in script.The rest of the code is for
different purpose if u want that also i dont know what advantage we will
get.The same files loaded without any issue in the second time.!!!
Please advise
Thanks,
Salih
Re: expr exit status
On Tue, Jan 19, 2010 at 3:37 PM, Alfred M. Szmidt a...@gnu.org wrote: What are all the exit statuses I need to check just after expr command? Is it only need to check 1 or 2 or 3 for fail condition and zero for success ?else pease specify You only need to check for non-zero exit codes for failure. --- Hi, But some case exit status is 1552 for expr even though the argument is integer .Initialy i checked if [ $?-ne 0 ],but this shows the above error that why i am planning to use kms=$? if [ $kms -eq 1 -o $kms -eq 2 -o $kms -eq 3 ] instaed of if [ $kms -ne 0 ] is it fine or will it make issues. The mannual says info expr|more Exit status: 0 if the expression is neither null nor 0, 1 if the expression is null or 0, 2 if the expression is syntactically invalid, 3 if an error occurred. Regards, Salih
