From: Kenny McCormack on
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
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
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
* 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
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?
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: SED help -
Next: AIX iconv question