Prev: SED help -
Next: AIX iconv question
From: Kenny McCormack on 4 Oct 2009 10:20 In article <1932915.qPjxIgIrBY(a)xkzjympik>, pk <pk(a)pk.invalid> wrote: .... >tr -d '\r' < file Of course, to be complete, you really have to say: tr -d '\r' < file > file.tmp mv file.tmp file And a true pedant could probably come up with more stuff; more edge cases that can cause the above to fail... Not to mention the fact that the above will lose permissions, ACLs, etc on the original file, so you might want to use an editor that re-writes files in place (not just pretends to like the -i switches found in various seds, perls, etc). I believe the original vi did this (re-writes in place) and that current VIM can be made to do so by setting the right options (alas, it doesn't do it by default).
From: pk on 4 Oct 2009 10:29 Kenny McCormack wrote: > In article <1932915.qPjxIgIrBY(a)xkzjympik>, pk <pk(a)pk.invalid> wrote: > ... >>tr -d '\r' < file > > Of course, to be complete, you really have to say: > > > tr -d '\r' < file > file.tmp > mv file.tmp file > > And a true pedant could probably come up with more stuff; more edge > cases that can cause the above to fail... > > Not to mention the fact that the above will lose permissions, ACLs, etc > on the original file, cat file.tmp > file rm file.tmp should keep the permissions. > so you might want to use an editor that re-writes files in place (not just > pretends to like the -i switches found in various seds, perls, etc). I > believe the original vi did this (re-writes in place) and that current VIM > can be made to do so by setting the right options (alas, it doesn't do it > by default). Just curious, how does one do true inplace editing when the length of the new text differs from the original? It seems to me that it would need moving forward/backwards the non-edited text to accommodate for that, which seems like an expensive thing to do if the file is huge (and probably unsafe in the case of a crash).
From: Kaz Kylheku on 4 Oct 2009 12:49 On 2009-10-04, Kenny McCormack <gazelle(a)shell.xmission.com> wrote: > In article <1932915.qPjxIgIrBY(a)xkzjympik>, pk <pk(a)pk.invalid> wrote: > ... >>tr -d '\r' < file > > Of course, to be complete, you really have to say: > > > tr -d '\r' < file > file.tmp > mv file.tmp file > > And a true pedant could probably come up with more stuff; more edge > cases that can cause the above to fail... Yes; like maybe you don't want to remove embedded carriage returns, but only ones which are in a CR-LF pair. > Not to mention the fact that the above will lose permissions, ACLs, etc > on the original file, so you might want to use an editor that re-writes > files in place (not just pretends to like the -i switches found in > various seds, perls, etc). Ah, well, that part can be done by a useful use of cat: # rather than mv! cat file.tmp > file Now the edited file remains the same filesystem object.
From: James Michael Fultz on 4 Oct 2009 18:03 * Kaz Kylheku <kkylheku(a)gmail.com>: > On 2009-10-04, Kenny McCormack <gazelle(a)shell.xmission.com> wrote: [...] > Yes; like maybe you don't want to remove embedded carriage returns, > but only ones which are in a CR-LF pair. $ awk '{sub(/\r$/, "")}1' < file > file.tmp >> [...editing file in-place in order to preserve permissions, etc...] $ printf ',s/\r$//\nwq\n' | ed -s file -- James Michael Fultz <xyzzy(a)sent.as.invalid> Remove this part when replying ^^^^^^^^
From: Jon LaBadie on 4 Oct 2009 21:39
James Michael Fultz wrote: > * Kaz Kylheku <kkylheku(a)gmail.com>: >> On 2009-10-04, Kenny McCormack <gazelle(a)shell.xmission.com> wrote: > [...] >> Yes; like maybe you don't want to remove embedded carriage returns, >> but only ones which are in a CR-LF pair. > > $ awk '{sub(/\r$/, "")}1' < file > file.tmp > >>> [...editing file in-place in order to preserve permissions, etc...] > > $ printf ',s/\r$//\nwq\n' | ed -s file > When did ed learn \r == ^M and when did it learn two letter commands? |