Appendfile adding a "^M"

I’m trying to create an update to a file and I think the concatenation is inserting this character inadvertently on RHEL systems. How do I prevent it from doing so?

# Example of overriding settings on a per-user basis^M
#Match User anoncvs^M
#       X11Forwarding no^M
#       AllowTcpForwarding no^M
#       ForceCommand cvs server^M

The append is inserting two new settings on the bottom but all the lines seem to end with this “^M”.

I don’t know what exact relevance you are using…but if you want to remove “^M” you can use the following statement in a curly braces and use appendfile.

appendfile {preceding texts of firsts “^M” of lines of file “test1234.txt”}

Can you provide the relevance / actionscript that you are using to do the concatenation? or the update?

This is likely happening due to using Windows line ending characters on a non-Windows system.

Correct …If we are able to know the relevance we can figure it out

The relevance is an appendfile that adds lines to the bottom of an existing file.

appendfile {concatenation "%0d%0a" of ( if (it contains (parameter "textToReplace" of action as string)) then ((preceding text of first (parameter "textToReplace" of action as string) of it) & (parameter "newtext" of action as string) & (following text of first (parameter "textToReplace" of action as string) of it) & "%0d%0a%0d%0a" & (parameter "newtext1" of action as string) & "%0d%0a" & (parameter "newtext2" of action as string) ) else it ) of lines of file (parameter "filePath" of action as string)}

I also believe this is due to the Windows line ending. I’m just wondering the best way to get rid of it. I thought, since the client is running and creating the file on the Linux side that it would create the file using Linux line endings… why doesn’t it?

I think it’s because the concatenation is adding them, the 0d, which is hex for ^M
So if this is running on Linux you only want to use line feed 0a in the concatenation.

1 Like

So rather than “%0d%0a” it should just be “%0a”?

1 Like

yep - that’s what I’m thinking.

This is because the line endings are actually being added by the concatenations in the relevance

1 Like

I’ll give it a whirl. Thanks.

1 Like

Every call to AppendFile will add a line ending for that OS, but if you are using relevance substitution with concatenation of a bunch of existing lines, then those line endings will be whatever you specified, which it will be up to you to have correct.

I wish windows would just treat “%0d%0a” as a single line ending like it does now, but also treat “%0a” by itself as a single line ending so that we could just standardized on a single line ending character for everything.

This is a historical nuisance thanks to the typewriter.

@jmaple,

Here’s what we use to get rid of those pesky M$ chars from app team scripts before running on *nix endpoints.

// Parse script, remote any Micro$oft escape characters and move to TMP filesystem
move __Download/script_name.sh /tmp/script_name.sh.tmp
delete __createfile
createfile until __END
{concatenation "%0a" of (concatenation "" of substrings separated by "%0d" of (it as string)) of lines of file "/tmp/script_name.sh.tmp"}
__END
move __createfile /tmp/script_name.sh
// Change script permissions and execute
wait chmod 744 /tmp/script_name.sh
wait /bin/sh /tmp/script_name.sh

Hope that helps.

@cmcannady

1 Like