Appendfile adding a "^M"

1

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”.

2

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”}

3

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.

4

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

5

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?

6

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
7

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

1 Like
8

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
9

I’ll give it a whirl. Thanks.

1 Like
10

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.

11

@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