I have the following code in a cgi script that just bundles up xml files into a zip for downloading:
my $obj = Archive::Zip->new();
foreach my $xml_file (glob(File::Spec->catfile($in_path,"*.xml")))
{
$obj->addFile($xml_file);
}
$obj->writeToFileNamed($zipfile_name);
This works fine on unit tests and when I run it on Linux, but when installed on windows, I get:
Can't call method "desiredCompressionLevel" on an undefined value at /usr/share/perl5/Archive/Zip/Archive.pm line 249.
In both cases, it works fine on Linux and under unit test, but fails when installed on windows (there are xml files in the directory that should be picked up...).
I think choroba's comment is correct. Since it only happens when you install on windows rather than when you test on windows, I'll bet that it is a "C:\Program Files" space issue. It is listed in the docs for perl's File::Glob:
Due to historical reasons, CORE::glob() will also split its
argument on whitespace, treating it as multiple patterns, whereas
bsd_glob() considers them as one pattern.
This could easily break things. The docs recommend using bsd_glob() instead of glob in this case.
I can cut and paste your code and run it on windows with $in_path == ".", but it breaks when I use $in_path = "C:\Path With Spaces". Also, with spaces, I am pretty sure it will fail on linux as well.
Related
I have Cygwin installed in order to use Linux command line tools on Windows. I also added it to my PATH. In general, it works fine, but I observe this weird behavior:
I want to run sha256sum on the file C:\Users\s1504gl\Desktop\Täst .txt. Note the german Umlaut ä and the whitespace before the file extension. In order to avoid problems with paths, I always quote paths in command line calls, such as:
sha256sum "C:\Users\s1504gl\Desktop\Täst .txt"
However, PowerShell returns
/usr/bin/sha256sum: '"C:\Users\s1504gl\Desktop\T'$'\303\244''st .txt"': No such file or directory
When I rename the file to either Täst.txt or Test .txt, it works. So the combination of the special character ä and the whitespace seems to cause the problem. Exchanging double quotes by single quotes does not change anything in this case.
I am pretty sure it has to to with PowerShell since the example works without any problems on my Linux machine.
Is there some other way of escaping special characters and/or blanks that I do not know?
Run from Cygwin terminal
sha256sum "/cygdrive/C/Users/s1504gl/Desktop/Täst\ .txt"
In general Cygwin program do not accept Windows paths and works surely with POSIX path
I found the following workaround:
I create a temporary file from R, containing all the necessary commands and then run this tempfile using bash which is also included in Cygwin. This way, I escape from the problem occurring due to different encodings in Windows and the Linux tools from Cygwin.
I have a program that checks to see if the files in my directory are readable,writeable, and executable.
i have it set up so it looks like
if (-e $file){
print "exists";
}
if (-x $file){
print "executable";
}
and so on
but my issue is when I run it it shows that the text files are executable too. Plain text files with 1 word in them. I feel like there is an error. What did I do wrong. I am a complete perl noob so forgive me.
It is quite possible for a text file to be executable. It might not be particularly useful in many cases, but it's certainly possible.
In Unix (and your Mac is running a Unix-like operating system) the "executable" setting is just a flag that is set in the directory entry for a file. That flag can be set on or off for any file.
There are actually three of these permissions why record if you can read, write or execute a file. You can see these permissions by using the ls -l command in a terminal window (see man ls for more details of what various ls options mean). There are probably ways to view these permissions in the Finder too (perhaps a "properties" menu item or something like that - I don't have a Mac handy to check).
You can change these permissions with the chmod ("change mode") command. See man chmod for details.
For more information about Unix file modes, see this Wikipedia article.
But whether or not a file is executable has nothing at all to do with its contents.
The statement if (-x $file) does not check wether a file is an executable but if your user has execution priveleges on it.
For checking if a file is executable or not, I'm affraid there isn't a magic method for it. You may try to use:
if (-T $file) for checking if the file has an ASCII or UTF-8 enconding.
if (-B $file) for checking if the file is binary.
If this is unsuitable for your case, consider the following:
Assuming you are on a Linux enviroment, note that every file can be executed. The question here is: The execution of e.g.: test.txt, is going to throw a standard error (STDERR)?
Most likely, it will.
If test.txt file contains:
Some text
And you launched it in your Perl script by: system("./test.txt"); This will display a STDERR like:
./test.txt: line 1: Some: command not found
If for some reason you are looking to run all the files of your directory (in a for loop for instance) be warned that this is pretty dangerous, since you will launch all your files and you may not be willing to do so. Specially if the perl script is in the same directory that you are checking (this will lead to undesirable script behaviour).
Hope it helps ;)
Ok, so here's my issue. I have written a build script in bash that pipes output to tee and sorts different output to different log files (so I can summarize errors/warnings at the end and get some statistics on files built). I wanted to use the colorgcc perl script (colorgcc.1.3.2) to colorize the output from gcc and had found in other places that this won't work piping to tee, since the script checks if it is writing to something that is not a tty. Having disabled this check everything was working until I did a full build and discovered some of the code we receive from another group builds C dependency files (we don't control this code, changing it or the build process for these isn't really an option).
The problem is that these .d files have the form as follows:
filename.o filename.d : filename.c \
dependant_file1.h \
dependant_file2.h (and so on for however many dependencies there are)
This output from GCC gets written into the .d file, but, since it is close enough to a warning/error message colorgcc outputs color codes (believe it's the check for filename:lineno:message but not 100% sure, could be filename:message check in the GCCOUT while loop). I've tried editing the regex to attempt to not match this but my perl-fu is admittedly pretty weak. So what I end up with is a color code on each line for these dependency files, which obviously causes the build to fail.
I ended up just replacing the check for ! -t STDOUT with a check for a NO_COLOR envar I set and unset in the build script for these directories (emulates the previous behavior of no color for non-tty). This works great if I run the full script, but doesn't if I cd into the directory and just run make (obviously setting and unsetting manually would work but this is a pain to do every time). Anyone have any ideas how to prevent this script from writing color codes into dependency files?
Here's how I worked around this. I added the following to colorgcc to search the gcc input for the flag to generate the .d files and just directly called the compiler in that case. This was inserted in place of the original TTY check.
for each $argnum (0 .. $#ARGV)
{
if ($ARGV[$argnum] =~ m/-M{1,2}/)
{
exec $compiler, #ARGV
or die("Couldn't exec");
}
}
I don't know if this is the proper 'perl' way of doing this sort of operation but it seems to work. Compiling inside directories that build .d files no longer inserts color codes and the source file builds do (both to terminal and my log files like I wanted). I guess sometimes the answer is more hacks instead of "hey, did you try giving up?".
I am currently using ActiveState Perl 5.14 and the R project version 2.13.2. Within Perl I am using Statistics::R version 0.08. According to ActiveState the more recent versions of Statistics::R (through 0.24) failed to pass scrutiny and are therefore not available through the PPM.
History: I have been successfully using Perl to access R for some time to perform analysis. Now I want to generate JPEG images of the results of the analysis for easy visualization.
Here's the problem: I can generate the images successfully from within the R console. However, when I run the same commands through Perl I only get a blank image. My console code includes (simplified, of course):
x<-c(1,2,3,4,5)
y<-c(5,4,3,2,1)
jpeg("C:/temp.jpg")
plot(x,y)
dev.off()
And my Perl commands include (also simplified):
$R = Statistics::R->new();
$R->start_sharedR
$R->send("x<-c(1,2,3,4,5)");
$R->send("y<-c(5,4,3,2,1)");
$R->send('jpeg("C:/temp.jpg")');
$R->send("plot(x,y)");
$R->send("dev.off()");
Any suggestions? I know that there are other plotting options accessible to Perl. I have eliminated some (GD Graph) because X-axis data is not treated as numeric. I'd prefer to keep it in R if at all possible since I'm already interacting in that package for the analysis. Thanks!
Forget Statistics::R. Just use a system call. At least it's what I do!
my $path_to_r = "C:/Program Files/R/bin/Rscript.exe";
my $cmd = "x<-c(1,2,3,4,5);";
$cmd .= "y<-c(5,4,3,2,1);";
$cmd .= 'jpeg("C:/temp.jpg");';
$cmd .= "plot(x,y);";
$cmd .= "dev.off()";
system($path_to_r . " -e '" . $cmd . "'");
If your R script grows up a bit or if it takes input from the parameters, write it in a file and Rscript.exe this file.
It works fine for me with Statistics R::0.27, but not with 0.08, the only version I could find in Active perl's package manager. In order to install 0.27, I had to use cpan command line. Make test fails but make install was fine. Bit of a life-saver.
(By the way I'm a relative noob. Using cpan command line was pretty easy however.
Type i /Statistics-R/ from cpan command line, then
install FANGLY/Statistics-R-0.27.tar.gz (or whatever the relevant file is. I'm using a windows system so RSPerl annoyingly not an option for me. I note that latest Statistics::R version is dated March 2012 so perhaps some of the previously documented (piping?) problems have been solved. You may also need to install a 'maker'; in my case it was 'dmake', not 'nmake'. Pretty easy, you can get a version of make from M$ website and copy that + .err file into PERL\bin dir. But help on this is available elsewhere. Hope this helps!)
Okay this is and isn't programming related I guess...
I've got a whole bunch of little useful console utilities scattered across a suite of projects that I wrote and I want to dump them all to a single directory to make using them simpler. The only issue is that I have them all compiled in both Debug and Release mode.
Given that I only want the release mode versions in my utilities directory, what switch would allow me to specify that I want all executables from my tree structure but only from within Release folders:
Example:
Projects\
Project1\
Bin\
Debug\
Project1.exe
Release\
Project1.exe
Project2\
etc etc...
To
Utilities\
Project1.exe
Project2.exe
Project3.exe
Project4.exe
...
etc etc...
I figured this would be a cinch with XCopy - but it doesn't seem to allow me to exclude the Debug directories - or rather - only include items in my Release directories.
Any ideas?
You can restrict it to only release executables with the following. However, I do not believe the other requirement of flattening is possible using xcopy alone. To do the restriction:
First create a file such as exclude.txt and put this inside:
\Debug\
Then use the following command:
xcopy /e /EXCLUDE:exclude.txt *.exe C:\target
You can, however, accomplish what you want using xxcopy (free for non-commercial use). Read technical bulletin #16 for an explanation of the flattening features.
If the claim in that technical bulletin is correct, then it confirms that flattening cannot be accomplished with xcopy alone.
The following command will do exactly what you want using xxcopy:
xxcopy /sgfo /X:*\Debug\* .\Projects\*.exe .\Utilities
I recommend reading the technical bulletin, however, as it gives more sophisticated options for the flattening. I chose one of the most basic above.
Sorry, I haven't tried it yet, but shouldn't you be using:
xcopy release*.exe d:\destination /s
I am currently on my Mac so, I cant really check to be for sure.
This might not help you with assembling them all in one place now, but going forward have you considered adding a post-build event to the projects in Visual Studio (I'm assuming you are using it based on the directory names)
xcopy /Y /I /E "$(TargetDir)\$(TargetFileName)" "c:\somedirectory\$(TargetFileName)"
Ok, this is probably not going to work for you since you seem to be on a windows machine.
Here goes anyway, for the logic.
# From the base directory
mkdir Utilities
find . -type f | grep -w Release > utils.txt
for f in $(<utils.txt); do cp $f Utilities/; done
You can combine the find and cp lines into one, I split them for readability.
To do this on a windows machine you'll need Cygwin or some such Unix Utilities handy.
Maybe there are tools in the Windows shell to do this...
This may help get you started:
C:\>for %i in (*) do dir "%~dpi\*.exe"
Used in the dir command as a modifier to i, ~dp uses the drive and path of everything found in (*). If I run the above in a folder that has several subfolders containing executables, I get a dir list of all of the executables in each folder.
You should be able to modify that to add '\bin\release\' following the ~dpi portion and change dir to xcopy. A little experimentation should make it pretty easy.
To use the for statement above in a batch file, change '%' to '%%' in both places.