I'm trying to issue a command that requires a line break due to a formatting restriction.
I need to commit a file to a CVS repository, but the repository has a restriction that requires a message to be included in the following format.
Change #: <number>
Description: <description>
The command used to commit the file is:
cvs commit -m "Change #: <number>\nDescription: <description>" <filename>
However when I issue the command it doesn't seem to be properly recognizing the line break and it fails saying that I gave it an invalid Change # and no Description.
How can I make it recognize the new line without it trying to issue two separate commands?
Try powershell in this format:
start-process -FilePath cvs.exe -ArgumentList "commit -m `"Change #:123 `nDescription:my description`""
I'm actually attempting to call this command from a Perl script and found an acceptable workaround. For some reason calling the command as a system command seems to fail, but if you call it using backticks it works fine.
# Fails
system 'cvs commit -m "Change #: <number>\nDescription: <description>" <filename>'
# Works
my $output = `cvs commit -m "Change #: <number>\nDescription: <description>" <filename>`
Whats funny is this difference in handling "\n" between using system commands and backticks doesn't seem to be documented anywhere.
Related
I am having trouble getting vimdiff to work on a Windows 10 machine. I am running vim from Powershell. Powershell is also declared in $myvimrc as my shell of choice:
set shell=C:\WINDOWS\system32\WindowsPowershell\v1.0\powershell.exe
The documents I am attempting to compare are not saved as files. I open two vertical splits, enter text into each, and run :windo diffthis. The output is E97: Cannot create diffs.
This article says I may need to download and use a different diff.exe than the one installed with gvim. I have downloaded the recommended "GnuWin32 diff" package and added the install directory to my Windows Path ($env:path). Continuing to follow these directions, I've commented out the default diffexpr declaration, but still get E97.
I have also tried calling my own function to no avail. In this attempt, I've made sure to escape backslashes, and have also copied the downloaded diff.exe to a directory I am confident I have full permissions to. To help with troubleshooting, I've temporarily saved the two files I wish to compare, and specified their full paths explicitly rather than using vim's v:fname_in and v:fname_new (and v:fname_out).
set diffexpr=TestDiff()
function TestDiff()
silent execute "!& " . "C:\\diff.exe" . " -a --binary " "C:\\a.edi" . " " . "C:\\b.edi" . " > " . "C:\\tmp.txt"
endfunction
I've researched this error by running :h E97, which returns the following information:
Vim will do a test if the diff output looks alright. If it doesn't,
you will get an error message. Possible causes:
The "diff" program cannot be executed.
The "diff" program doesn't produce normal "ed" style diffs (see above).
The 'shell' and associated options are not set correctly. Try if filtering works with a command like ":!sort".
You are using 'diffexpr' and it doesn't work. If it's not clear what the problem is set the 'verbose' option to one or more to see
more messages.
The self-installing Vim for MS-Windows includes a diff program. If
you don't have it you might want to download a diff.exe. For example
from http://gnuwin32.sourceforge.net/packages/diffutils.htm.
I believe that I pass the first two of these requirements, as tmp.txt is generated and follows the example "ed" style diff that is provided in the help file. I have not set other shell-related parameters (shelltype, shellpipe, etc) in $myvimrc, but executing other commands with :! complete without issue.
There is no additional information in :messages, only the E97 error.
Edit:
If I remove set shell=C:\WINDOWS\system32\WindowsPowershell\v1.0\powershell.exe from $myvimrc, defaulting the shell back to cmd.exe, diffthis works as expected. It seems that others have also had this problem when using Powershell.
Below are captures of the command windows that pop up when running diffthis with both shells. The commands used are nearly identical.
I had speculated that the forward slashes apparent in the Powershell version of this attempt were problematic, but I am able to run this command exactly (with dummy files in place of the .tmp files) and it outputs what seems to be an adequate file for use with diff. I've also tried adding a substitute of forward slashes to back slashes to no avail.
The problem boils down to how vim/Powershell are A) encapsulating the command in quotes and B) handling white space in path names.
I am able to bypass this problem with the following changes to $myvimrc:
set shell=powershell
set shellcmdflag=-c
set shellquote="
set shellxquote=
Also a change in the default MyDiff() function within the if that sets the path to diff in the cmd variable:
" below is the default
" let cmd = substitute($VIMRUNTIME, ' ', '" ', '') . '\diff"'
let cmd = "C:/diff"
This approach is dependent upon copying the diff.exe that ships with vim to a directory that doesn't contain spaces in the path for simplicity (C:\diff.exe).
The resulting command that is executed is:
powershell -c C:/diff -a --binary C:/<redacted>/a.tmp C:/<redacted>/b.tmp > C:/<redacted>/c.tmp
Is there any equivalent for "git log --grep="STRING" in windows?
I've written a python program for linux which requires a reading of commit logs that contain certain string from the git object. This worked fine in linux, but when I ran the same program in windows, git log --grep="STRING" catches nothing.
Here's the code snippet. (fetcher.py)
import os
...
os.chdir(DIRECTORY) # where git obj is
command = "git log --all --grep='KEYWORD' > log.txt"
os.system(command) # run the command in the shell
...
It seems that git internally uses the linux grep for the "--grep" argument such that Windows cannot run this correctly as it misses grep.
Thanks for your help.
As I am not getting any answer for 24 hrs,
I suggest my own solution, which does not utilize grep.
Because git log itself runs without any problem,
I just ran the command without the --grep='STRING' option, then read the output from the shell (or a file) to filter the commit logs which contain 'STRING' by the use of regular expression.
import os
import re
command = "git log --all > log.txt"
os.system(command) # run the command in the shell and store output in log.txt
with open('log.txt', 'r') as fp:
gitlogoutput = fp.readlines() # read the redirected output
if gitlogoutput:
commits = re.split('[\n](?=commit\s\w{40}\nAuthor:\s)', gitlogoutput)
# it splits the output string into each commits
# at every '\n' which is followed by the string 'commit shahash(40bytes)\nAuthor: '
for commit it commits:
if 'KEYWORD' is in commit:
print commit
The approach requires you to add some code, but I believe it does the same thing as the original command does. For better results, you can change the last if statement which is,
if 'KEYWORD' is in commit:
into something that can do more sophisticated search e.g. re.search() method.
In my case, this produced exactly the same result as that of --grep="KEYWORD"
Still, I appreciate your help :)
It seems that git internally uses the linux grep for the "--grep" argument such that Windows cannot run this correctly as it misses grep.
It certainly can, provided your %PATH% includes <git>/usr/bin (which has 200+ Linux commands compiled for Windows)
See this simplified path:
set G=c:\path\to\latest\git
set PATH=%G%\bin;%G%\usr\bin;%G%\mingw64\bin
set PATH=%PATH%;C:\windows\system32;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\
Add the PATH for python, and you can "Linux grep" without any issue.
In Windows, use the following format (replacing the = sign with a space):
git log --grep "STRING"
I am a complete newb with bashrc and I want to shortcircuit a command in the termal.. display a message with a "y/n" prompt. If I type "y", then the original command I did goes thru.
I don't think this is hard, I just need a push in the proper direction. I did some searching and nothing seemed to even hint at anything like this.
for example:
I type:
cvs -m commit /some/file/structure
because I put: "cvs -m commit"
bash intercedes, and displays message:
"Please make sure you......"
continue with command "y/n":
something along those lines. Thanks a bunch.
.bashrc only gets executed when starting the shell, not for every command, I don't know how it could help. If there's a certain command that you wish to add confirmation to, you could build an alias or a little script with the same name as the original command, and make sure it's in the PATH before the real command. The script can read its arguments and pass them to the original command after displaying the y/n prompt.
I have a bash script and I want to use ncftp to do something. if I have this:
#!/bin/sh
HOST='my_IP_FTP_HOST'
USER='username'
PASSWD='password'
ncftp -u $USER -p $PASSWD $HOST <<END_SCRIPT
pwd
quit
END_SCRIPT
I get this error:
Syntax error in parameters or arguments
I don't understand why.
If I give it only the value and not the variables it works...
if I launch
$ sh -x script.sh
I get:
+ HOST=$'xxx.x.xx.xx\r'
+ USER=$'username\r'
+ PASSWD=$'password\r'
+ ncftp -u $'username\r' -p $'password\r' $'xxx.x.xx.xx\r'
NcFTP 3.2.1 (Jul 29, 2007) by Mike Gleason (http://www.NcFTP.com/contact/).
Welcome to FTP server
Syntax error in parameters or arguments
hmmm.... \r creates problems sure.
Are you editing this file on Microsoft Windows? It doesn't works because the original file uses Windows carriage returns, which are passed to variables and then to ncftp, which then halts.
Fix it by using another text editor, or by using dos2unix. Ideally you'd first use dos2unix once and then change the text editor.
Alternatively (but really, really not recommended) you could just parse the variables and remove the extra \r, like below, especially when the problem arises at some input reading, which doesn't seems to be the case here.
HOST=${HOST%\\r}
USER=${USER%\\r}
PASSWD=${PASSWD%\\r}
Take care when copying text from Windows, or when editing without appropriate software.
I'm trying to write a script that contains this
screen -S demo -d -m which should start a new screen session named demo and detach it.
Putting screen -S demo -d -m in the command line works.
If I put it in a file named boot.sh, and run it ./boot.sh I get
Error: Unknown option m
Why does this work in the command line but not as a shell script?
This file was transferred from windows and had ctrl-M characters.
Running "screen" on my Linux machine, a bad option (Screen version 4.00.03jw4 (FAU) 2-May-06) gives the error,
Error: Unknown option -z"
while your description includes no dash before the offending option. I'd check that the characters in your script file are what you expect them to be. There are many characters that look like a dash but which are not.
cat -v boot.sh
may show something interesting as it'll show codes for non-ascii characters.
This may seem a little like the "make sure your printer is plugged in" kind of help, but anyway:
have you tried to check if the screen you're invoking from the script is the same as the one invoked from the command line ?
I'm thinking you may change the PATH variable inside your script somewhere and perhaps screen from the script would be something else (a different version, perhaps ?).