Robert P. J. Day wrote: > nitpicky, yes, but it occasionally irritates me that "cut" will > print fields, not in the order you specify them with the "-f" option, > but in the original order in the source text, to wit: > > $ cut -d: -f1,7 /etc/passwd > root:/bin/bash > bin:/sbin/nologin > daemon:/sbin/nologin > ... > > $ cut -fd: -f7,1 /etc/passwd > root:/bin/bash > bin:/sbin/nologin > daemon:/sbin/nologin > ... > > is there really a reason that cut refuses to acknowledge the order > of the fields as supplied by the user? some historical reason, > perhaps, that we can now all make fun of and wonder what they were > smoking at the time? > > rday > From the man page: Use one, and only one of -b, -c or -f. Each LIST is made up of one range, or many ranges separated by commas. Selected input is written in the same order that it is read, and is written exactly once. I am not sure, but I suspect that cut just checks to see if the data being read matches one of the fields it is supposed to match, and it it does, then it prints it. This would go along with it being designed as a filter. I suspect that it does not analyze the entire line, and then print the matched fields, but instead analyzes the line as it goes, printing the parts that match the filter criteria. Remember, cut dates back to when resources were limited, and was designed to be a "building block" to be combined with other programs in shell scripts to do complicated tasks. As such, it was designed to perform a simple task quickly, and with minimal resource usage. There were more complicated programs, with higher resource usage, for when you need more then it provides. Mikkel -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
Attachment:
signature.asc
Description: OpenPGP digital signature
