I used the following to remove ^M in all files - I guess i did it in haste 
find / -name "*" | xargs perl -p -i -e 's/^M//g' *
It changed all my LIBRABRIES since i used -- perl -p -i -e 's/^M//g' *
Is there some way to revert this from my libraries . Does any revert command exits for the Control M in libraries. I believe my libraries are corrupted now.
Regards,
Telecomics
Sorry, but in this case a R&R (reboot and restore) is called for.
It is not - not even theoretically - possible to revert this because it is not clear where the "^M"s have been: You have EOLs which are preceeded by a ^M and EOLs which aren't. It is easy to search for the ones which are and change them - like you have done. But now you have only EOLs which aren't preceeded by ^M and if you now add a ^M before each of them your libraries will perhaps be as corrupted as they are now because there will be any number of superfluous ^Ms in there.
I hope this helps - if only to avoid it the next time.
bakunin
As a minor correction to what bakunin wrote, actually ^M doesn't stand for carriage return, it means the character M at beginning of line (i.e. beginning of file or immediately after a line feed).
Hm, I would think it depends on what the poster has really typed when he entered the perl statement's substitution.
If he pressed ^V and then hit Enter then ^M should represent \015.
But if he actually only typed a caret (or circumflex) followed by upper case M,
yes than it just represents those Ms.
Maybe he should pipe his statement from the history into an octal dump to make sure?
$ echo ^M|od -t a
0000000 cr nl
0000002
$ echo ^M|od -t a
0000000 ^ M nl
0000003
It's really immaterial; the pivotal point here is that it cannot be undone.
I never questioned that.
As the other poster already said, it's time to role the restore from the backup.
Just an aside,
if you (the thread issuer) like me have your filesystems on LVM volumes (yes I do have a separate lv_usr)
there is a neat feature that can be used for rolling back quickly from an unfortunate experiment like yours without even rolling a regular backup.
Before I do such dubious recursive substitutions I just would create a snapshot volume of the affected LV like
[root@toshsat:~]
# df /usr
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/vgfc-lv_usr
5160576 3193892 1704540 66% /usr
[root@toshsat:~]
# vgdisplay vgfc|egrep 'PE Size|Free PE'
PE Size 8.00 MB
Free PE / Size 11 / 88.00 MB
[root@toshsat:~]
# lvcreate -s -n snapof_usr -l 11 /dev/vgfc/lv_usr
Logical volume "snapof_usr" created
[root@toshsat:~]
# lvs -o lv_name,lv_size,origin,snap_percent vgfc
LV LSize Origin Snap%
lv_depot 9.80G
lv_home 512.00M
lv_opt 512.00M
lv_root 1.00G
lv_tmp 512.00M
lv_usr 5.00G
lv_usr_local 256.00M
lv_var 1.00G
snapof_usr 88.00M lv_usr 0.01
Above I only created a snapshot of 88 MB of the 5 GB /usr volume because I hadn't any more free PEs in my vgfc.
Normally, one would adapt this to the size of the snapped of LV and the anticipated amount of changes during the period one would possibly require the snapshot.
As a rule of thumb 10% suffice, but this depends on the changes in the filesystem.
Since /usr is pretty static (and even could be mounted ro often) there won't be many changes.
From the lvs command above you can watch the filling up of the snapshot with the changes.
Once the snap_percent approaches 100% your snapshot is useless and can't be any longer used for recoveries.
Now you can safely run your command.
If something goes wrong, you simply mount the snapshot volume ro somewhere and run your restore.
Once you no longer need your snapshot simply lvremove it.
[root@toshsat:~]
# mount -r /dev/vgfc/snapof_usr /mnt/tmp2
[root@toshsat:~]
# df /usr /mnt/tmp2
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/vgfc-lv_usr
5160576 3193892 1704540 66% /usr
/dev/mapper/vgfc-snapof_usr
5160576 3193892 1704540 66% /mnt/tmp2
[root@toshsat:~]
# umount /mnt/tmp2
[root@toshsat:~]
# lvremove -f /dev/vgfc/snapof_usr
Logical volume "snapof_usr" successfully removed
You are right, of course. The reason for this is the only way i ever had to use "^M" was to remove DOS-style CR/LFs from text documents, like
sed 's/^M$//' document
therefore seeing the "^M" evocated this Pavlovian reflex in me - "use of ^M must mean remove CR/LFs" and i didn't even read any further. Of course "^M" means, in the normal sense of a non-escaped character, an M at the beginning of a line like you pointed out correctly.
Sigh, this comes from working in DOS/Windows-contaminated environments for too long. I probably got infected.
bakunin
Despite what bufoonix wrote, you can do what you are trying to do... To do it right, however, you must replace the \015 character with another character, such as a space (\020).
The thing is, you really don't want to replace all instances of \015, because that might represent code or some piece of instruction, initialization data, etc. You have to be more selective. Try something like this (and test it !!)
perl -p -i -e 's/\015(\012)/ $1/gs' *
At least this way you get \015s coupled before a newline. The problem is trickier, however, since in some compilers, something like, "strchr(string, crnl)", the "crnl" is actually "\r\n" and the strchr library handles that as a special case. I'm not sure what will happen if you substitute a space-newline in there!
I can imagine other sorts of headaches you might encounter.
Hi.
I suspect that because the OP began at /, there were also executables that were changed.
A filter to eliminate non-text items would be the first step I would suggest. The command file makes good guesses about the content of files, but it varies among systems, so one would need to do a few experiments first.
Running commands and scripts with an echo in front of the command that will do the real work is often a good idea. One then can see what will get changed, and the process can be fine-turned until it meets the requirements.
This was a good learning experience -- tough, but good -- and I think many of us have had that happen at least once. It underlines the usefulness of backups. Currently I do a lot of work in virtual machines, and the snapshot is very easy, not dissimilar to what buffoonix outlined for LVM volumes. I do that for almost every update that is made available. There was a number of weeks when GNU/Debian testing updates made a mess of fonts and the desktop. I did snapshots and restored until they got it straightened out ... cheers, drl
Thanks for all your replies .
Just to mention, Ctrl V and then Ctrl M was used to replace the characters in the executed command which changed most of my jar and lib files.
My Sysadmin can backup the filesystem using /usr/openv/netbackup/bin/bp command
Is it better to replace just the libraries that were changed on that mountpoint (they are too many including the ./java/jre/lib ) or the entire mountpoint since my vignette application is "installed" on Solaris at /apps dir , would replacing the entire /appl directory be sensible ?
Another observation - No binary files were changed - signifying they dont have any such control chars.
Restore as much as you can and start over, would be my advice.