[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Undocumented cut feature
Re: Undocumented cut feature
Fri, 26 Oct 2007 11:00:00 -0600
Please when sending replies ensure that the bug-coreutils address
remains in the recipient list. This allows the group to participate
in the discussion and others to learn from it. This is most easily
done by using the group reply action of your mail client. Thanks.
Gambs, David (CONT) wrote:
> For some reason some of the code does not appear correctly. So I
> repost here with meta-characters expanded.
> /sbin/vgdisplay > /home/user/file1
> cat /home/user/file1 | egrep -e Name -e "PE Size" -e Free > /home/user/file2
> cut -b 22- /home/user/file2 > /home/user/file3
> cut -f2 -d' ' /home/user/file3 > /home/user/file1
Can you post the contents of file3? On my system the vgdisplay output
starts in column 25 and not 22 and so my results are quite different.
I expect to see something like this:
11870 / 46.37 GB
> By bringing each file into vi I found the ^M on ONLY the vg name line
> and only in the final file1. It was not in file2 nor file3.
Thanks for debugging that. But your example depends upon your
'vgdisplay' output. Since this is text data we should be able to
reduce the test case around cut to be just the data that goes into it
and the data that comes out of it and we won't need to have vgdisplay
involved in the test case. Something like this:
$ cut -f2 -d' ' file3
$ cut -f2 -d' ' file3 | od -tx1 -c
0000000 76 67 31 0a 4d 42 0a 47 42 0a
v g 1 \n M B \n G B \n
Can you show us the contents of your file3 that is given to cut to
operate upon and produces your file1 with the bad data? That will be
the critical piece of information to debug this problem.
> When I just captured the output from vgdisplay and looked at it in
> vi, it was not there either. I had this as a straight pipe but did
> not get the vg name in the final output which had all three on a
> single line - the ^M would wipe out the vg name.
I don't understand. Could you post the exact example?
> > And we are at core utilities: coreutils-4.5.3-28.4
> However, the issue was cleared in coreutils-5.2.1-31.6
Good data points. But if so then I believe it was probably related to
native language support added by the vendor. In which case you would
need to work through your vendor to acquire a patch that would be
compatible with your system.
> I do like your method of getting the info into variables and that would
> allow me to output things better, although I think your way will have an
> array on each variable when there is more than one vg on the system
> (something the client has all over the place).
Ah, yes, multiple volume groups. I had not accounted for that in my
example. Good observation. Of course I do not know what you are
doing with the strings of data after the point that you have shared
> The reason we want this is so it is easier to figure out if there is
> space on systems for an additional or expanded FS or if we have to add
> more SAN to the system. When looking for space and you have fifty or
> more VGs you really want just one liners for each VG.
That sounds reasonable. In order to understand where the carriage
return is coming from we need exact data going into and coming out of
the suspect command.