In RStudio, when I am writing a multi-line comment in a text file, such as a makefile, is there a way I can comment out several lines besides hitting return and entering a # at the start of each line?
Related
I want to download a huge file from s3 to a server so I'm using nohup.
Problem is, the process outputs "self-updating reports", which are cool in the terminal but are horrible when written to a file as a single long line.
My questions are:
How should I handle this output to avoid a 84MB text file of just one line?
Given that I have such a file, how can I read its "bottom line" effectively?
thanks!
The "self-updating" text is just a carriage return character, which when printed to the terminal moves the cursor back to the beginning of line, allowing you to overwrite any previous text on the line.
To remove everything up through the last carriage return character,
awk '{ sub(/.*\r/, ""); }1' file
or the same with any regex tool (sed 's/.*\r//' file would work if your sed recognizes the nonstandard \r escape).
Some tools have an option to turn off progress updates; if you are using the standard aws s3 cp, try adding the option --no-progress.
I am using Windows and MobaXterm.
I created a .bash_profile file in the ~ directory and the following line
alias sbp="source ~/.bash_profile"
is the only code in that file.
However, when I was trying to do sbp, I got an error.
This works on my Mac and it used to work on my old Windows computer (but that one has some water damage so it broke down). Why does this not work now?
Thanks in advance!
From the way that error message is garbled I'm pretty sure that the .bash_profile file you created has DOS/Windows-style line endings, consisting of a carriage return character followed by a newline character. Unix tools expect unix-style line endings consisting of just a newline; if they see DOS/Windows-style endings, they'll treat the carriage return as part of the content of the line. In this case, bash will treat the carriage return as part of the alias definition, and therefore part of the filename to filename to source. Try running alias sbp | cat -vt to print the alias with invisible characters shown; my guess is it'll print alias sbp='source ~/.bash_profile^M' (where the ^M is cat -vt's way of representing the carriage return).
Solution: convert the file to unix format, and either switch to a text editor that knows how to save in unix format, or change your settings in the current editor to do it. For conversion, there are a number of semi-standard tools like dos2unix and fromdos. If you don't have any of those, this answer has some other options.
BTW, the reason the error message is garbled is that the CR gets printed as part of the error message, and the terminal treats that as an instruction to go back to the beginning of the line; it then prints the rest of the message over top of the beginning of the message. It's a little like this:
-bash: /home/dir/path/.bash_profile
: No such file or directory
...but with the second line printed over the first, so it comes out as:
: No such file or directory_profile
On Ubuntu, inside of a bash script, this ran ( along with some other commands ):
sudo jmeter -n -t test.jmx -l /home/ubuntu/apache-jmeter-2.13/bin/results.jtl
When I do a "ls", I see this file with a question mark in the filename for some reason results.jtl?. I believe this is because there is a new line at the end of the file after the last line of the .jtl:
"
"
That question mark character in the file name is causing me problems. If I open the file with nano, manually delete the newline out of the file and save the file as results.jtl, then I can use the .jtl file like normal.
How can I get JMeter to save the .jtl without adding that newline to the end of the .jtl?
If that is not possible, how can I fix this? I would like to avoid using code to read the file and make adjustments. I would think there should be a more straightforward answer to this.
I also tried to open some of my other scripts involved and remove any white-space or new lines at the end of those scripts. This has not helped either, though. I was thinking about why the "?" would be in the file name, to begin with, and trying any solutions.
Furthermore, if I deleted the "results.jtl?" file and ran the JMeter command on the command line, not inside a bash script file, then JMeter did not save it with the ? in the file name. So, it's only when the bash script is run that the ? is in the file name.
I don't have a huge amount of experience using VI. I am running it on Mac OSX.
I've copied and pasted text before in the editor using (when I say gui in the following I mean the Mac OSX gui)
Cursor to highlight and copy i using command C or the gui or the yy command in VI.
Entering insert mode where I want to paste the text and then pasting using command V or the gui
My problem is that a very long line that is split over multiple lines in the terminal becomes multiple lines as shown on the terminal when copied and pasted by any of the methods.
How do I get it to copy and paste excatly as is?
Move the cursor to the line from where you want to copy and paste contents at another place.
Hold the key v in press mode and press upper or lower arrow key according to requirements or up to lines that will be copied. you can press key V to select whole lines.
Press d to cut or y to copy.
Move the cursor to the place where you want to paste.
Press p to paste contents after the cursor or P to paste before the cursor.
You have
:set paste
Put Vim in Paste mode. This is useful if you want to cut or copy
some text from one window and paste it in Vim. This will avoid
unexpected effects.
Setting this option is useful when using Vim in a terminal, where Vim
cannot distinguish between typed text and pasted text.
Assuming your vi is actually vim, before pasting, do:
:set paste
That disables word wrapping and auto-indent and all similar things that modify typed text. After pasting, turn it off again with
:set nopaste
The reason is that while gvim can tell pasting from typing (so you don't need this when using gvim), the terminal version can't, because it's the terminal doing copy and paste and vim simply sees the text as typed. And therefore applies the transformation like it does for any other text.
Someone showed me a neat trick. In the vi editor, set to insert mode ("i"). Then middle-button click at the location where you would like to insert.
Well, if it is actually one long line the easiest way to do this is with a 'Y' in command mode. Just move to the line and do Y and then move to where you want to put the line and do a p (for paste).
After trying everything suggested here and in other answers including trying to format the file afterwards with vi(m) commands and seds, I got smart and just heredoc'd what I wanted to paste with redirection to the file. i.e.
cat << EOF > yourfile.txt
paste what you are trying to paste
another line of pasted text
yet another
foo > bar?
foo = bar??
end of the file(yay)
EOF
everything between the first line and the last line will be pasted to your file without those pesky newlines interpreted as many spaces/tabs. Just beware that what you are pasting might have its own heredoc(like mine did coincidently LOL). In that case would need to manually paste those lines in your editor which shouldn't be an issue.
I'm attempting to apply a patch to a file with Windows line endings on a Linux system and I'm getting conflicts due to the carriage returns in the file.
The -l option (ignore whitespace) isn't ignoring the EOL characters. Is there anyway to get patch to ignore windows style line endings?
Try using the --binary option, from the manpage (emphasis mine)
--binary
Write all files in binary mode, except for standard output and /dev/tty. When reading, disable the heuristic for transforming CRLF line endings into LF line endings. (On POSIX -conforming systems, reads and writes never transform line endings. On Windows, reads and writes do transform line endings by default, and patches should be generated by diff --binary when line endings are significant.)
I don't fully understand the above, but it worked for me on a Linux machine to apply a Unix patch onto a DOS file.
Here's a link http://www.chemie.fu-berlin.de/chemnet/use/info/diff/diff_2.html
The -w' and--ignore-all-space' options ignore difference even if one file has white space >where the other file has none. White space characters include tab, newline, vertical tab, >form feed, carriage return, and space
Run diff like: diff -w file1.txt file2.txt
I work around this using the following commands to convert all files of interest to unix line endings.
dos2unix `grep Index\: mixed-line-ending.patch | sed -e 's/Index\://'`
dos2unix mixed-line-ending.patch
patch -p0 < mixed-line-ending.patch
I had this problem with a diff that was manually copied and pasted from git diff console output, into a patch file with LFs. To get that patch file to work again - to be able to be applied on the actual files that were using CRs and LFs - several things had to be done manually:
find all instances of "^M" and drop them
add CR to all lines within the hunks - but not the meta format lines (## etc)
on all lines within hunks that were empty, add the missing space in the first column
joe syntax highlighting was very helpful there, because it colored hunks properly as soon as I fixed them.
Tell patch to ignore white space:
-l, --ignore-whitespace
Causes the pattern matching to be done loosely, in case the tabs
and spaces have been munged in your input file. Any sequence of
whitespace in the pattern line will match any sequence in the
input file. Normal characters must still match exactly. Each
line of the context must still match a line in the input file.
This ignores mismatches of EOLs too -- at least, on FreeBSD, using patch version 2.0-12u11.