In the Maven Windows prerequisites, it states,
You need to unpack the Maven distribution. Don't unpack it in the middle of your source code; pick some location (with no spaces in the path!) and unpack it there.
Why does it matter if there are spaces in the path or not?
The problem is that somewhere in Maven, it is executing a sub process and it is not properly wrapping its file name arguments in double quotes. So a file that is at
"C:\Program Files\Foobar"
will look like 2 files on the command line
"C:\Program"
"Files\Foobar"
and neither of those are correct. This is a holdover from the "old" days when spaces were not allowed in file names (ie 1980s) and spaces separated arguments on the command line. It's a shame that this problem still exists. It's slightly worse on Linux machines, which have been slower to migrate to allowing spaces in file names, so there are more scripts and programs on Linux which fail if you have spaces in the file names.
Related
When I try to create an electron app via yarn create electron-app "my-app", it throws an error saying
'C:\Users\Lincoln' is not recognized as an internal or external command,
operable program or batch file.
error Command failed.
Exit code: 1
Command: C:\Users\Lincoln Muller\AppData\Local\Yarn\bin\create-electron-app
Arguments: my-app
Directory: C:\Users\Lincoln Muller
Output:
What should I do? I'm new to Yarn, and NPM worked fine. This also only happens on Windows, when I use my iMac on Monterey or my Linux laptop the command runs fine.
It seems that Yarn assumes it can run the program create-electron-app without considering spaces in the file path. Unfortunately, this does not work and only the part up to the first space is considered a program to run, hence you get the error message that C:\Users\Lincoln is not a valid command.
The problem is discussed in this Yarn issue. The key idea in the workarounds is to accept Yarn's behavior and give it a file path that doesn't contain spaces. There are two concrete ideas:
Option A - Use directory name abbreviation to skip the space
yarn config set cache-folder "C:\Users\Lincol~1\AppData\Local\Yarn\Cache"
yarn config set prefix "C:\Users\Lincol~1\AppData\Local\Yarn"
For this to work, make sure to take 6 characters from the actual directory name and then append ~1. If the space happens to occur within the first 6 characters, this approach will not work for you.
Option B - Make another user folder, skipping the space (using junction)
mklink /J "C:\Users\Lincoln-Muller" "C:\Users\Lincoln Muller"
yarn config set cache-folder "C:\Users\Lincoln-Muller\AppData\Local\Yarn\Cache"
yarn config set prefix "C:\Users\Lincoln-Muller\AppData\Local\Yarn"
A junction allows two directory names to point at the same file system structure. That means that there are two ways to address the same directory. Their contents cannot diverge because they are the same directory.
The issue is that you have a space in your directory name and you haven't correctly escaped it.
C:\Users\Lincoln Muller
This looks like you are trying to pass the parameter Muller to program C:\Users\Lincoln
I suggest just using a folder that doesn't contain spaces or escape the [space character].
https://www.howtogeek.com/694949/how-to-escape-spaces-in-file-paths-on-the-windows-command-line/
Three Ways to Escape Spaces on Windows There are three different ways
you can escape file paths on Windows:
By enclosing the path (or parts of it) in double quotation marks ( ”
).
By adding a caret character ( ^ ) before each space. (This only
works in Command Prompt/CMD, and it doesn’t seem to work with every
command.)
By adding a grave accent character ( ` ) before each space.
(This only works in PowerShell, but it always works.)
I just ran the command
echo $PATH
The output was:
/opt/anaconda3/condabin:/usr/local/opt/python/libexec/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/opt/X11/bin
Why is it so long? Shouldn't it look more like
/usr/local/bin?
It is quite normal to have a PATH variable that is long. Yours contain some duplicate entries but this is not a real problem.
If you execute a command without specifing a path the shell searches in each path specified in the PATH variable to find it. In your example it search in /opt/anaconda3/condabin and after that in /usr/local/opt/python/libexec/bin and so on.
It is normal to have multiple places for executables and thus multiple entries in the PATH variable separated with colon. Often third party software like Anaconda in your example adds it own folder to the PATH variable.
Have a look at /etc/paths, /etc/paths.d and your shell profile where those path might be added.
And from a security standpoint your PATHS could be risky if /opt/anaconda3/condabin or /usr/local/opt/python/libexec/bin is writeable by the user/others as anybody can place malicious executable there masking the system supplied ones in /bin or /usr/bin.
If not absolutely neccessary third party pathes should be added to the end as they normally shouldn't replace existing binaries.
I am trying to create a batch file that copies files from one path to another, using several xcopy commands. However, the batch script fails because Xcopy apparently has the wrong number of parameters.
I believe the reason is that it thinks the spaces in my folder paths are separating parameters- but I do not know why it is doing this because I have made sure that both the source and destination paths are surrounded with double-quotes.
for example, I run this command in my batch script:
c:/windows/system32/xcopy.exe "H:\some path with spaces\myfile.txt" "H:\some path with spaces\a_different_folder\myfile.txt" /Y
and it outputs this:
Invalid number of parameters
Can somebody please tell me what I'm doing wrong or if there is a workaround?
I have also tried using the standard copy command, but that ends up saying the system cannot find the path specified (which isn't true, as my batch file is actually generated by a script that uses the paths of files that are guaranteed to exist)
as #Mark said:
It is your path to xcopy. It is wrong. It is why you are getting the message. C: is a valid command. It will choose a valid command over fixing unix's paths
I am currently looking at this project (Mattermost) that has a certain line in the makefile that I'm confused about:
$(GO) run $(GOFLAGS) $(GO_LINKER_FLAGS) ./cmd/platform/*.go --disableconfigwatch &
What is the meaning of ./cmd/platform/*.go? What specific files are executed? The program executes correctly when I type it in the terminal.
I am trying to enter the command line arguments in an IDE but I need a specific entry file.....
Wikipedia
glob (programming)
In computer programming, in particular in a Unix-like environment,
glob patterns specify sets of filenames with wildcard characters. For
example, the Unix command mv *.txt textfiles/ moves (mv) all files
with names ending in .txt from the current directory to the directory
textfiles. Here, * is a wildcard standing for "any string of
characters" and *.txt is a glob pattern. The other common wildcard is
the question mark (?), which stands for one character.
Clearly, ./cmd/platform/*.go, starting in the current directory, looks in the cmd/platform directory for files matching the wildcard *.go.
The ls ./cmd/platform/*.go command will list the files on Linux.
So, the go run ./cmd/platform/*.go command compiles and runs these Go (*.go) source files. See Command go documentation: Compile and run Go program.
I have written a batch script that logs into my ftp server, then navigates to a directory. I am having trouble with the mget command, I want it to download every .dat file in the directory, but it simply returns this error:
Cannot access file '/home/minecraft/multicraft/servers/server267/world/players/*.dat':No such file or directory.
200 Type set to: ANSI
Cannot find list of remote files
Here is my script (ran from cmd)
open 66.71.244.202
USER
PASSWORD
cd /world
cd players
mget *.dat
That is by design. The most recent update to the FTP specification (RFC 3659) explicitly forbids it (see section 2.2.2):
For the commands defined in this specification, all pathnames are to be treated literally. That is, for a pathname given as a parameter to a command, the file whose name is identical to the pathname given is implied. No characters from the pathname may be treated as special or "magic", thus no pattern matching (other than for exact equality) between the pathname given and the files present in the NVFS of the server-FTP is permitted.
Clients that desire some form of pattern matching functionality must obtain a listing of the relevant directory, or directories, and implement their own file name selection procedures.
When you execute your script file with ftp, you have to turn off the globbing which will allow the use of wildcards in the script. For example:
ftp -n -i -s:scriptfile.txt
should work but
ftp -n -i -g -s:scriptfile.txt
will not.
I know this is old, but it might help someone. I had the same issue with wildcards on MGET from Windows FTP, but it was not consistent in that it worked talking to some remote systems, but not to all of them.
My script was doing this:
cd /folder/folder
mget ./-400TA/folder/*_XYZ
In the folder structure I have a set of different folders that begin with hyphens, and for whatever reason the script CD's down to just above there, and uses the relative path in the MGET. I had the same issue that some of you reported, that if I connected interactively and typed the commands one by one, it worked. But in batch, it didn't.
I followed the suggestions in this and other posts, but no joy. I don't have access to the remote systems at the moment to look at them to figure out why some worked and some didn't.
However, what I did find was this. Changing my script as follows:
cd /folder/folder/-400TA/folder
mget *_XYZ
did the trick. Simple. There's some strange interaction going on somewhere possibly with folder protections or something, but it just shows that trying out different things may get you there in the end.
I would make sure glob is on, when turned off the file name in the put and get commands is taken literally and wildcards will not be looked at.
More info:
glob:Toggle filename expansion for mdelete, mget and mput. If globbing
is turned off with glob, the file name arguments are taken literally
and not expanded. Globbing for mput is done as in csh. For mdelete and
mget, each remote file name is expanded separately on the remote
machine and the lists are not merged. Expansion of a directory name is
likely to be different from expansion of the name of an ordinary file:
the exact result depends on the foreign operating system and ftp
server, and can be previewed by doing ‘mls remote-files -’ Note: mget
and mput are not meant to transfer entire directory subtrees of files.
That can be done by transferring a tar archive of the subtree (in
binary mode).
Once you are inside your ftp try to check the glob and set it on if it is off. The default behaviour is on, from the command line when connecting to ftp with the option -g you can turn off the file name globbing.
It could very well also be a firewall issue where it is not permitting or forwarding the servers inbound connection. Happened to me.