Does anyone know of a command line exe/tool that will reliably trim whitespace from the end of lines for the C# language?
Does it have to be command line? Visual Studio will when you do a Format Document (Ctrl+E+D or Ctrl+K+D depending on keyboard layout).
alias trimfile="sed -r 's~[[:space:]]+\$~~g' -i"
Related
I have following snippet:
host="https://example.com"
port="80"
url="${host}:${port}"
echo $url
the output is:
:80ps://example.com
How can I escape the colon here. I also tried:
url="${host}\:${port}"
but it did not work.
Expected output is:
https://example.com:80
You've most likely run into what I call the Linefeed-Limbo.
If I copy the code you provided from StackOverflow and run it on my machine (bash version 4.4.19(1)), then it outputs correctly
user#host:~$ cat script.sh
host="https://example.com"
port="80"
url="${host}:${port}"
echo $url
user#host:~$ bash script.sh
https://example.com:80
What is Linefeed-Limbo?
Different operating systems use different ASCII symbols to represent when a new line occurs in a text, such as a script. This Wikipedia article gives a good introduction.
As you can see, Unix and Unix-like systems use the single character \n, also called a "Line Feed". Windows, as well as other systems, use \r\n, so a "carriage return" followed by a "line feed".
What happens now is when you write a script on Windows on an editor such as notepad, what you write is host="example.com"\r\n. When you copy this file into Linux, Linux interprets the \r as if it were part of the script, since only \n is considered a new line. And indeed, when I change my newline style to DOS-style, I get the exact output you get.
How can I fix this?
You have several options to fix this issue.
Converting the script (with dos2unix)
Since all you need to do is replacing every instance of \r\n with \n, you could use any text-editing software you want. However, if you like simple solutions, then dos2unix (and its sister unix2dos) might be what you looking for:
user#host:~$ dos2unix script.sh
dos2unix: converting file script.sh to Unix format...
That's it. Run your file now and you will see it behaves well.
Encoding the source-file correctly
By using a more advanced text editor such as Notepad++, you can define which style of newline you would like to use.
By changing the newline-type to whichever system you intend to run your script on, you will not run into any problems like this anymore.
Bonus round: Why does it output :80ps://example.com?
To understand why your output is like this, you have to look at what your script is doing, and what \r means.
Try thinking of your terminal as an old-fashioned typewriter. Returning the carriage means you start writing on the left again. Making a "new line" means sliding the paper. These two things are seperate, and I think that's why some systems decided to use these two characters as a logical "new line".
But I digress. Let's look at the first line, host="https://example.com"\r.
What this means when printed is "Print https://example.com, then put the carriage back at the start". When you then print :80\r, it doesn't start after ".com", it starts at the beginning of the line, because that's where you (unknowingly) told the cursor to go. it then overwites the first few characters, resulting in ":80ps://example.com" to be written. Keep in mind that after 80, you again placed a carriage return symbol, so any new text you would have written ends up overwriting the beginning again.
It works for me, try to remove carriage returns in variables and then try.
new_host=$(echo "$host" | tr -d '\r')
new_port=$(echo "$port" | tr -d '\r')
new_url="${new_host}:${new_port}"
i'm in Visual studio 2010 debugger using the Python tools plugin (which is FABULOUS by the way). i set my command line args to 'BON7%09/13' and I want that passed in as a string. Now visual studio tells me I have two command line args, not one: "BON7" and "/13". This is because %09 is ascii code for tab, and it's converting the char. But I don't want that conversion. How do I block it?
I tried all the usual escapes (single quotes around the string, double quotes around the string, backslash in front of the %) but none of those help. How do I make visual studio treat that command line arg as pure text?
For what it's worth, it doesn't convert the %09 when I run from command line without Visual Studio. Also, I tried the same thing in C# but it works fine there.
You could try a work around of using %3709 which if consumed as you described should create %09.
I am using grep to take all the four letter words out of a dictionary text file and place them into a new text file.
This command should work with Unix however on windows it does not.
I need one word per line, on windows it gives me all the words but all piled together without spaces.
This is the grep command I'm using:
grep "^[a-z]\{4\}$" dictionaryfilename > outputfilename
I believe it's something to do with a difference in newline characters between Unix and windows?
Anyway I'm not sure how to make a fix for windows with this could someone please help.
Thanks a lot :)
you probably have a UNIX-formatted textfile (newlines without carriage returns), which looks like one big line in Windows; grep just deals in whatever the system says is 'a line', so it has little to do with the problem.
Try converting the file from LF to CRLF and see if you get better results.
I generate a csv file (example.csv) using an oracle procedure (utl_file.put_line), but when i open the file with notepad, i realize that there is an CR (carriage return) at the end of the file. I just want to remove that CR.
The file is generated on a server UNIX (AIX), and i open it on my computer (windows) using notepad.
Thanks fo your help
This seems the wrong way around. Newline in Unix is line feed (LF) and on Windows is carriage-return line feed (CRLF).
If you're creating a file in Unix and opening it in Windows I would expect few problems as Windows normally works out that you meant newline by LF. If you're doing it the other way around, generating the file in Windows and opening in Linux you should probably expect a stray character on the end of each line.
The documentation says that utl_file.put_line "appends an operating system-specific line terminator." This means that the problems you're experiencing make little sense. There should be a LF on the end of each line. Furthermore, even if Oracle was doing this incorrectly and appending a Windows newline it'll be CRLF.
It may be that Notepad for some reason is appending a CR on the end, though this doesn't really make much sense.
A work around, if you're always going to be viewing the file in windows is to use utl_file.put, which doesn't include the operating system specific newline on the end and concatenate CRLF on the end.
Something line, utl_file.put( filename, theline || chr(13) || chr(10) ); where chr(n) returns the character with the values n in your character set. 13 is the Ascii for carriage return and 10 for new line.
The easiest and most common way to solve this problem is using this tool unix2dos. Run this command on your unix box and then open new_example.csv file on your window
here is the command for you:
unix2dos -n example.csv new_example.csv
Extending Ben's answer:
You can also use utl_file.put_line( filename, theline || chr(13));
The output is the same [CR][LF] at the end of the line.
I once write a simple sed command like this
s/==/EQU/
while I run it in command line:
sed 's/==/EQU' filename
it works well, replace the '==' with 'EQU', but while I write the command to a script file named replace.sed, run it in this way:
sed -f replace.sed filename
there is a error, says that
sed: file replace.sed line 1: unknwon option to 's'
What I want to ask is that is there any problem with my script file replace.sed while it run in windows?
The unknown option is almost invariably a rogue character after the trailing / (which is missing from your command line version, by the way so it should complain about an unterminated command).
Have a look at you replace.sed again. You may have a funny character at the end, which could include the ' if you forgot to delete it, or even a CTRL-M DOS-style line ending, though CygWin seems to handle this okay - you haven't specified which sed you're using (that may help).
Okay, based on your edit, it looks like one of my scattergun of suggestions was right :-) You had CTRL-M at the end of the line because of the CR/LF line endings:
At the end of each line in the *.sed file, there was a 'CR\LF' pair, and that the problem, but you cannot see it by default, I use notepad to delete them manually and fix the problem. But I have not find a way to delete it automatically or do not contain the 'new-line' style while edit a new text file in windows.
You may want to get your hands on a more powerful editor like Notepad++ or gVim (my favourite) but, in fact, you do have a tool that can get rid of those characters :-) It's called sed.
sed 's/\015//g' replace.sed >replace2.sed
should get rid of all the CR characters from your file and give you a replace2.sed that you can use for your real job.