How do I define a Windows file path as a variable? - perl

I am screwing around with a tiny script I am making and one thing I am trying to figure out is how to make a perl variable reflect an executable, for example.
$putty = C:\putty.exe;
When ever I run it like this it tells me "C:\ is not recognizable command, what am I doing wrong? I have also tried surrounding it in quotes and no help by that.

You should be quoting literal strings, for example like
my $putty = 'C:\putty.exe';
If this is news to you, you might have been missing out on the strict pragma before. I highly recommend having a look at that and using it in all of your code.

Related

Perl - Requires explicit package name

I have googled around and looked online and I understand a few criteria would need to be met in order to get this function to work, however, I don't understand why it's able to work in the first place.
Context:
I have a Perl script that I want to integrate into a Perl module. The situation is that I'm new to the language and I'm a bit unsure the difference and I don't understand why this error is coming up in the first place.
The Perl module is this:
https://github.com/slic3r/Slic3r/blob/master/lib/Slic3r/Print/SupportMaterial.pm
I thought I could just add the script into the module and be done, but unfortunately, that is not the case due to the error message. Now to what I know so far as someone new to Perl, you need to declare them "my ..." or remove use strict. I am somewhat interested in the latter since the script is working correctly. Does anyone have any help or tips?
Now to what I know so far as someone new to Perl, you need to declare them "my ..." or remove use strict. I am somewhat interested in the latter since the script is working correctly. Does anyone have any help or tips?
Declaring the variables with my is the right approach. use strict does an number of things - forcing variable declaration is only one of them.
No serious Perl programmer would consider writing code without use strict and use warnings. Removing them is a bad idea.

How to understand this perl multi-line writing command

I am trying to understand the perl commands below:
$my = << EOU;
This is an example.
Example too.
EOU
What is the name of this way? Could somebody can explain more about this "multi-line writing" command?
Essentially the syntax is allowing you to put anything unique as a marker so that it won't conflict with your contents. You can do this:
$my = <<ABCDEFG;
This is an example.
Example too.
BLAH
ABCDEFG
Everything between "This.." and "BLAH" will be assigned to the variable. Note that you shouldn't have a space after the << symbols otherwise you will get a syntax error. It helps avoid adding CR characters, or append (.) everywhere, and useful when passing data into another application (eg. ftp session). Here Documents is the correct term for this.
Everything between <<EOU and EOU is a multi-line, non-escapable, string. It's nothing fancy, think of them as start and end quote marks with nothing inside requiring escapes to be literally what you typed...

How to get powershell to read and interpret VS2013 variables (macros)?

I was looking at some of the macros in VS2013 and noticed that some use what look to be something like powershell syntax calls inside of the registry (less the macros $(VCTargetsPath) and $(MSBuildExtensionsPath32)).
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\12.0\12.0
VCTargetsPath REG_SZ $([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V120\'))
I tried to execute it, but powershell doesn't seem to understand the type [MSBuild].
How can I interpret this easily, without parsing and translating what it seems to be obviously doing?
NOTE
My goal is to parse a .vcxproj file and extract information from it. This requires that I evaluate the Condition tag attributes, which in turn require that I expand and evaluate them. If I'm going down the wrong path and you know something about how to do this, then please point me in the right direction.

What is a good method for inventing a command name?

We're struggling to come up with a command name for our all purpose "developer helper" tool, which we are using on our project. It's like a wrapper for our existing tools like cmake and hg. The purpose of the command is really just to make our lives easier by combining multiple commands into one (for example, publishing packages). For example, we have commands like:
do conf
do build
do install
do publish
We've considered a few ambiguous names like do (as above) and run, but obviously, do is a Linux bash command and run is pretty ambiguous.
We'd like our command to be 2 chars short, preferably - but who thinks we're asking the impossible? Is there a practical way to check the availability of command names (other than just typing them into your terminal), or is it just a case of choose one and hope nobody else will use it? Are we worrying about nothing?
Since it's a "developer helper" tool why not use hm [run|build|port|deploy|test], Help Me ...
Give it a verbose name, then let everyone alias it to whatever they want. Make sure you use the verbose name in other scripts so that it removes ambiguity.
This way, each user gets to use whatever makes sense to him/her, and the scripts are more readable and more easily searchable (for example, grepping four "our_cool_tool" will usually yield better results than grepping for "run").
How many 2-character words are useful in this context? I think you need four. With that in mind, here are some suggestions.
omni
torq
fluf
mega
spif
crnk
splt
argh
quat
drul
scud
prun
sqat
zoom
sizl
I have more if you need them.
Pick one: http://en.wikipedia.org/wiki/List_of_all_two-letter_combinations
To check the availability of command names, I suggest looking for all two-letter filenames that are in the directories in your path. You can use a script like this
for item in `echo $PATH | sed 's/:/ /g'` ; do
ls -1d $item/??
done
It won't show builtins in your shell (like "do" as you mentioned) but it's a good start.
Change ?? to ??? for three-letter files, etc.
I'm going to vote for qp (quick package?) since it's easy to pronounce, easy to type, and easy to remember where the keys are on the keyboard.
I use "asd". it's short and most developers type it without thinking
(oh, and you can always claim later that it stands for some "Advanced Script for Developers" if you need to justify yourself a few years from now)
How about fu? As in Kung Fu. It's a special purpose tool. And it's really easy to type.
I think that run is a good name, at least anybody that will download your project will know what to do. Calling it without parameters should reveal your options.
Even 'do' will do, I think you can use backquotes to run it from bash scripts.
Also remember that running the tools without parameters will tell you what options you have.
Use makefiles to do everything for you.
How about calling it something descriptive, like 'build_runner', and then just aliasing it to 'br' (or preferred acronym) in your .bashrc?
There is a really crappy tool called cleartool (part of clearcase), and people will alias it on their machine to "ct". Perhaps you can have a longer command and suggest users alias it.
It would probably be best to do something like ire_and_curses suggested, name it descriptively then alias it to a 2 letter command. If I was choosing, I would name it dev_help and alias it to dh.
I think you're worrying about nothing. Install the program as 'the-command-to-do-evertyhing-and-if-you-dont-make-your-own-alias-for-it-you-should'. I don't think that will be too long for any modern filesystems, but you might need to shorten it to 'tctdeaiydmyoafiys'. See what common aliases are used, and then change the program's name to that. In other words: don't decide, let natural selection decide for you. If you are working with a team of < 10, this should not even remotely cause any problems.
Call it devtool alias to dt
Custom tools like that I like to start with the prefix 'jj-'. I can type (with big index-finger power) 'jj ' and see all my personal commands. Also, they group together in alphabetical lists. 'J' is not a very common character for built-inc commands, but you can pick your own.
Since you want two characters, you can use just 'zz', or something starting with 'z'.
Are you sure you want to put all your functionality in one command? That might be simultaneously over-constraining and over-loading the interface a little.
do conf
do build
do install
do publish

Best way to run external app only if it exists

I've got a Perl script that as one of its final steps creates a compressed version of a file it has created. Due to some unfortunate setups, we cannot guarantee that a given customer will have a specific compression function. I want to put something like this together:
if ($has_jar) {
system("jar -c $compressed_file $infile");
}
elsif ($has_zip) {
system("zip -j $compressed_file $infile");
}
else {
copy($infile, $compressed_file);
}
Where if they don't have either of the compression apps, it will just copy the file into the location of the compressed file without compressing it.
My sticky wicket here is that I'm not quite sure what the best way is to determine if they have jar or zip. It looks like I can used exec() instead of system() and take advantage of the fact that it only returns if it fails, but the script actually does do a couple of things after this, so that wouldn't work.
I also need this to be a portable solution as this script runs on both Windows and various Unix distros. Thanks in advance.
I think your best bet is File::Which.
See my multi-which.
For *nix based systems, this should work:
my $has_jar = `which jar` ne '';
This could potentially work for Windows as well if you include which.
Alternatively, you could try the command suggested by this answer,
my $has_jar = `for %i in (jar.exe) do #echo. %~$PATH:i` ne '';
It most likely doesn't return '' if it doesn't find it, however, but I don't have Perl available on a Windows machine to test it out.
Look through the directories specified by the PATH environment variable.
Usually, things like that don't suddenly disappear from the system, so I suggest to check the presence of the tools during setup/installation and save the one to use in the config.
How about just try to run the program. If it can't be run, then you know there's a problem.
Why not use the Archive::Zip package to do the compression, eliminating the need for an external program altogether?
There are a couple of things to think about if you are going to do this:
Use system and exec in the list form so the shell doesn't get a chance to interpret special characters.
Can you store this as configuration instead of putting it in the code? See how CPAN.pm does it, for instance.
How do you know that you are running what you think you are running? If someone makes a trojan horse of the same name, is your program going to happily execute it? Note that using the PATH, as noted in Sinan's multi-which, still has this problem since it relies on the user setting the PATH.