This is my input file :
FCBAFE572C5E4BA29B3F8030BD480A94,907 ,1/1/2003,12/31/2005,ACT,1,2010-05-07 04:42:26.380000
2345AD5D2BFB29C821C1BC3DE8B746A7,907 ,1/1/2004,1/31/2005,ACT,1,2010-05-07 04:42:26.380000
E45B7371EEC0D1AB00E1750B5BC661F7,907 ,1/1/2004,12/31/2006,ACT,1,2010-05-07 04:42:26.380000
I am using this command :
cut -d ',' -f 1,2,4,3,5 f1.txt > temp.txt
but the output is still formed in the existing order rather the order i have mentioned.
Can anyone help?
You could postprocess with awk or sed to swap fields. Awk would gladly do the cut, too.
Hi.
The only cut I know that prints in the order you specify is on AIX, so I think you're stuck with it.
Use awk, or something else, instead.
i.e.
awk -F, '{print $1, $2, $4, $3, $5}' OFS=, f1.txt > temp.txt
The HP-UX "cut" behaves the same. It just outputs your selection of fields working left-to-right regardless of the order of the parameters on the command line.
@scottn :
The solution provided by you was really good.
I just want to make that reusable.
The values $1,$2,$4,$3 will be passed from a variable.
Can we loop this awk script by getting the required as parameters as input ?
Sounds like a nice addition to open source cut code, if it is missing. Oops, it is now a Google world, so I should go look myself; apparently, opinions vary and IBM does as it pleases:
Interesting!
I've just looked at a couple of our older AIX's and can't reproduce the behaviour I said existed.
But I vividly remember debugging a problem when migrating a script from AIX to Linux that exhibited odd behaviour, and it was because cut on the AIX box was preserving the order as given on the command line.
That server has since been rebuilt and is at a higher technology level.
So, either
a) I dreamt it (vividly!)
b) there was such a version distributed at some point in time
c) someone went to some trouble to replace standard cut with a modified one
Oh well, it's no big deal 
It was a bug, so IBM fixed it! Maybe you reported it! It was useful -- we cannot have that! 
Hi,
I did not loop the awk script but found an easier solution like the one given below.
Right now it is working well on my AIX server.
But when i migrate the same to my LINUX server, its not executing.
Can anyone help..
pk1=1,3,2,4
mc1=6,5
pkcols1=`echo $pk1 | sed 's/,/,$/g'`
cols1=`echo $mc1 | sed 's/,/,$/g'`
awk -F, '{print'`echo "$"$pkcols1",$"$cols1`'}' OFS=, file1.txt
Try nawk?
I used the command dos2unix while moving the file from my windows to linux server and it worked perfectly 
But i do want to know what exactly does this command do.. because when i transfer my file from windows to my AIX box, my code works fine even without converting.
Is this something specific to LINUX?
---------- Post updated at 09:25 PM ---------- Previous update was at 01:57 PM ----------
I am stuck up with yet another change to this code..
While the following code helps me to cut the columns in the required layout and create a new file, the file generated is comma separated. Is there a way where i can define which delimiter my output file should contain?
pk1=1,3,2,4
mc1=6,5
pkcols1=`echo $pk1 | sed 's/,/,$/g'`
cols1=`echo $mc1 | sed 's/,/,$/g'`
awk -F, '{print'`echo "$"$pkcols1",$"$cols1`'}' OFS=, file1.txt
I cannot use a sed and replace the comma with the delimiter i need, because my input file might contain comma in the data. :(
What usually matters is how you transfer the file. For example "ftp" in text mode will do the conversion for you. This is not specific to AIX or Linux.
I recall it is mostly add/remove carriage returns before line feeds for dos and not for UNIX (but life also includes cr in place of lf for Apple, and then there is EBCDIC, unicode, UTF-8, . . . . ).
The line terminator for text files in unix is one character: linefeed.
The line terminator for text files in MSDOS is two characters: carriage-return, linefeed.
@methyl . . . and for Apple, just a CR.
The CR comes before the linefeed because the carriage on the teletype needs a lot of time to move up to 8+ inches to the left, more compared to the time to raise the platen roller and paper 1/6 of an inch. Some of that time came from the stop and parity bits at the end of the serial, asynchronous data characters, but slow devices on fast lines needed null padding characters. Nobody seemed to have the right formulas to correctly pad for a form feed, not that you wanted to buy that much paper.
Luckily, only Notepad insists on CR; email, Wordpad and Word do not.
Man pages come with embeded backspace for underlining and bold, but who has a paper terminal any more? Sometimes, paper print programmers used the CR alone to overprint the line for bold, underline or strikeout.