I'm trying to use the call operator (&) to run an R script, and for some reason I am unable to direct to the right path on the D:\ drive, but it works fine on the C:\ drive (copied the R folder from D:\ to C:\ for testing).
The D:\ drive error appears like a space error, even though there are quotes around the string/variable.
Double spacing between "Program" and "Files", the call command reads correctly.
Ideally I would like to call to Rscript.exe on the D:\ drive, but I don't know why it's giving me an error - especially when the C:\ drive works fine and double spacing reads correctly.
Also worth noting "D:\Program Files (x86)" doesn't read correctly either, with similar symptoms.
Update: running
gci -r d:\ -include rscript.exe | % fullname
returns:
D:\Program Files\R\R-3.2.3\bin\i386\Rscript.exe
D:\Program Files\R\R-3.2.3\bin\x64\Rscript.exe
D:\Program Files\R\R-3.2.3\bin\Rscript.exe
The last of which is what my variable $RscriptD is set to.
The first error message in your image is:
Rscript.exe : The term 'D:\Program' is not recognized as an internal or external command
This message means that the call operator (&) called Rscript.exe but Rscript.exe failed to do something by using 'D:\Program'.
I don't know exactly the details of internal process of Rscript.exe, however, I think Rscript.exe tried to run D:\Program Files\R\R-3.2.3\bin\i386\Rscript.exe or D:\Program Files\R\R-3.2.3\bin\x64\Rscript.exe but could not handle the whitespace of Program Files. Because the manual says:
Sub-architectures are also used on Windows, but by selecting executables within the appropriate bin directory, R_HOME/bin/i386 or R_HOME/bin/x64. For backwards compatibility there are executables R_HOME/bin/R.exe and R_HOME/bin/Rscript.exe: these will run an executable from one of the subdirectories, which one being taken first from the R_ARCH environment variable, then from the --arch command-line option and finally from the installation default (which is 32-bit for a combined 32/64 bit R installation).
According to this, I think it is better to call directly i386/Rscript.exe or x64/Rscript.exe rather than bin/Rscript.exe which is just for backwards compatibility.
Related
I am using Windows Powershell (on windows 10). I am also using the latest version 2.3.0.5 of docker desktop. When I type "docker version" in powershell the command is not recognized. The error message reads "Der angegebenen Datei ist keine Anwendung zugeordnet." (English: No application is assigned to the specified file). When I instead include the file extension and type "docker.exe version" the command can be executed. The interesting thing is that "docker version" works in a cmd window, but for some reason not in powershell. The extension ".exe" is contained in the windows environment variable PATHEXT.
What could be the reason that it doesn't work in powershell?
PS: I had an old version of docker installed before. There everything worked fine. Then I updated to the newest version. After that I couldn't use my existing docker containers anymore. So I uninstalled the old version and installed version 2.3.0.5. Since then I have this issue.
tl;dr:
Run Get-Command -All docker | ForEach-Object Path
Among the file paths returned, remove those that do not end in *.exe (use Remove-Item).
The likeliest explanation is that, in one of the directories in your system's path ($env:PATH) that comes before the one in which docker.exe is located, contains another file whose base name is docker:
Either: It is an extension-less file literally and fully named docker [This is what it the problem turned out to be] .
PowerShell unexpectedly tries to execute this extension-less file, because it considers it executable, despite - by definition - not having an extension designated as executable via the PATHEXT environment variable ($env:PATHEXT).[1]
This would explain cmd.exe's different behavior, because it sensibly never considers an extension-less file executable.
Presumably, the uninstallation of the old Docker version removed the original docker.exe, but left an extension-less docker file in the same directory behind (possibly a Unix shell script).
Or: It does have an extension (other than *.exe), which:
refers to a file that isn't directly executable and needs an interpreter - a separate executable - in order to be executed
and that extension is listed in the PATHEXT environment variable
and the association between the filename extension (e.g., .py) and the (information about the) associated interpreter is (now) missing, possibly as a result of having uninstalled the older Docker version.
[1] In fact, PowerShell unexpectedly considers any filename extension executable - see GitHub issue #12632.
However, for those extensions not listed in PATHEXT, execution via the path only works if you include the filename extension in a file-name-only call (e.g., executing file.txt opens a file by that name located in the first folder in the path that has such a file in the associated editor). With an extension-less file, there is obviously no extension to include, which is why confusion with an *.exe file of the same base name is possible (unless you invoke with .exe); if both such files reside in the same directory in the path, the *.exe file takes precedence, but if the extension-less file is in a different directory listed earlier in the path, it takes precedence.
I run PowerShell on Windows 10 and uses mingw and WinAVR side by side.
I want to use both make provided by mingw and WinAVR. (For some reason using mingw's make causes problems when working with Arduino code.)
But I can't add both C:\WinAVR-20100110\utils (contains WinAVR make) and C:\Program Files\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin to paths because they have executables with the same name.
Can I do something like, prepending every command provided by WinAVR by avr (make to avr-make)? Or is there another walk around?
You can:
add the directory of the one executable that you do want to invoke as make to your $env:Path (first) - C:\Program Files\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin
define the other as an alias, by adding the following to your $PROFILE file:
Set-Alias avr-make C:\WinAVR-20100110\utils\make.exe
Note that alias have higher precedence than executables.
See about_Aliases and about_Command_Precedence.
If you want to define such aliases for all executables in a given directory, use the following approach:
Get-Item C:\WinAVR-20100110\utils\*.exe | ForEach-Object {
Set-Alias ('avr-' + $_.BaseName) $_.FullName
}
I am using PowerShell v5 and trying to archive the file with the Compress-Archive cmdlet from Microsoft.PowerShell.Archive module:
Compress-Archive -LiteralPath $GLBSourcePathFull -CompressionLevel Optimal -DestinationPath $GLBArchiveFile
This worked flawlessly with 3 files, which had the following sizes: 16MB, 341MB and 345MB.
However once it came across the files bigger in size than 600MB (approximately), PowerShell threw the following exception:
Exception calling "Write" with "3" argument(s): "Exception of type 'System.OutOfMemoryException' was thrown."
The same thing happened with files over 1GB in size.
To add more context to my situation, I am trying to zip up the file from the local folder to one of the network locations within my company, however I doubt there is a difference as I tested this on my local PC just to get the same results.
Have you ever encountered this before? Is it trying to read the whole file into memory before outputting the zip instead of writing directly to the disk? Or maybe there is a limit to how much memory PowerShell can use by default?
I know there are a few other solutions like 7Zip4powerShell module, but I am not allowed to use anything open source at this point, so I would like to understand the current situation I have and how I could potentially address this.
Thank you for any comments you may have.
Compress-Archive cmdlet probably uses a naive approach of loading/mapping the entire source file and target archive into memory and since you're apparently using 32-bit PowerShell these files (along with the PowerShell process code and other data used by the process) don't fit into the process address space which is 2GB (or 3-4GB if it's LARGEADDRESSAWARE).
64-bit PowerShell on a machine with lots of RAM (e.g. 32GB) successfully compresses 1GB+ files.
If you're stuck with 32-bit PowerShell and the built-in cmdlet, try splitting the file into 100MB files and use some descriptive file names to be able to join them in your unpacking script. Obviously such an archive would be unusable for anyone without the re-assembling script.
I have done this .bat file to copy some maps and textures from my USB drive to the valve installation path, but it doesn't work, why?
#echo on
COPY \CS-Fix\Maps\*.* %PROGRAMFILES%\Valve\Half-Life\cstrike\maps
COPY \CS-Fix\Textures\*.* %PROGRAMFILES%\Valve\Half-Life\cstrike\
ERASE %PROGRAMFILES%\Valve\Half-Life\cstrike\maps\de_shipment.bsp
pause
What is wrong?
The %PROGRAMFILES% indicates that you're using Windows, not MS-DOS.
MS-DOS was Microsoft's variant of DOS, an operating system that preceded Windows.
Anyway, two main problems are apparent to my tired eyes:
Paths that possibly have spaces and are not quoted.
Probably no write access to the relevant folders.
To fix the first problem, quote paths.
The second problem is only a problem in Windows Vista and later.
You can probably fix that by running the batch file from an elevated command prompt.
I assume that the batch file is sitting on and being run from your thumb drive.
Do the paths need to be quoted?
#echo on
COPY "\CS-Fix\Maps\*.*" "%PROGRAMFILES%\Valve\Half-Life\cstrike\maps"
COPY "\CS-Fix\Textures\*.*" "%PROGRAMFILES%\Valve\Half-Life\cstrike\"
ERASE "%PROGRAMFILES%\Valve\Half-Life\cstrike\maps\de_shipment.bsp"
pause
You might need to quote things. %PROGRAMFILES% probably expands out to C:\Program Files. Try something like this:
#echo on
COPY "\CS-Fix\Maps\*.*" "%PROGRAMFILES%\Valve\Half-Life\cstrike\maps"
COPY "\CS-Fix\Textures\*.*" "%PROGRAMFILES%\Valve\Half-Life\cstrike\"
ERASE "%PROGRAMFILES%\Valve\Half-Life\cstrike\maps\de_shipment.bsp"
pause
I'm using backticks to run an external command in perl, but I've got a problem.
What I want to do is to run
`mount /dev/sdb2 /mnt`
But the sdb2 is only the right parameter when I'm running it with this disk, I want to be able to run the script with any disk.
The script gets information about the source disk that I'm using (in this case the sdb), and puts it as "$source". But when I try the:
`mount $source /mnt`
It says "mount: you must specify the filesystem type"
In this case the program asks for the "2"
Any idea on how to make the script find the number that is requried, or at least how to add a "2" after the "$source" so that
$source = /dev/sdb2 and not /dev/sdb
Use curly braces when expanding the variable:
`mount ${source}2 /mnt`
NB. make sure you validate $sources value, as to not introduce code injection vulnerabilities.