I'm writing a command which uses the environment variable CC. If CC is set, my command makes a system call to $CC, otherwise cc is used. When invoking cc, should I use /usr/bin/cc or simply cc? Can I even rely on cc existing in /usr/bin? Since a user can set CC to any string I think using the path to cc provides no extra safety.
cc is not part of the POSIX standard, so you cannot assume any particular location for it. (Really, the same is true for any command; that is what PATH is for.) Your script has one documented requirement, which is that it be able to run some command to compile code.
By default, that command is cc.
You can modify PATH to influence which cc gets used.
You can set CC to be more specific; it can be another command name, a relative path, or an absolute path.
Note that CC and PATH are not mutually exclusive. If CC is set to an absolute path, that will be used. If you just use something like CC=gcc, then the value of PATH can still determine which of several installed versions of gcc are used.
Related
I've been referencing files in my scripts with a period to indicate the current execution directory of the script, such as ".\images\test.png" but I've discovered that I could also point to the same file with $PSScriptRoot\images\test.png.
Is there an argument to be made for one over the other? When using the PS ISE, the former requires that I CD into my script directory before running code, but the scripts will normally be run automatically so the PWD should always be localized in scope. Is there another case I'm not considering?
ED: I suppose I should have specified that I am asking in the case of an independent script that is executed in isolation (it's invoked directly and does not invoke other scripts), which probably leads to the edge case of the current location and location of the current script are one in the same. In less specific conditions that I failed to consider, I can see more divergence.
The direct answer to your question as to "is there a difference" is yes, there is a substantial difference.
The difference is that . is a reference to the current location. If the current location is a different location than where the script is, then it will not be the same as $PSScriptRoot. For example:
PS C:\> C:\Scripts\Test-Script.ps1
Inside Test-Script.ps1, . will refer to C:\ but $PSScriptRoot will refer to C:\Scripts.
I would like to move files filtered using wildcards to subfolders, however perforce move does not accept my usage of the wild card.
given this structure
filea_mk1.txt
fileb_mk2.txt
mk1/
mk2/
to move all files some thing like p4 move ./... ./mk1/... works, however when replacing the selected file to use wild cards I get:
p4 edit filea_mk1.txt
p4 move *_mk1*.* ./mk1/...
Usage: move [-c changelist#] [ -f ] [ -k ] [-t type] from to
Missing/wrong number of arguments.
I have thought about using p4 fstat as that does accept the wildcards, and could then pass filenames into to xargs.
p4 fstat *_mk1*.*
However I can not get the -A options correct to only show client names.
TL;DR
Is there a way to filter *_mk1*.* into the mk1 folder and *_mk2*.* into the mk2 folder, using perforce commands?
Instead of this:
p4 move *_mk1*.* ./mk1/...
Do this:
p4 move "*_mk1*.*" "mk1/*_mk1*.*"
Note the double quotes to keep the shell from expanding the asterisks.
Alternatively, this simpler form will probably work fine unless the paths are trickier than your example makes them appear:
p4 move ..._mk1... mk1/..._mk1...
I believe that what's happening here is that your operating system shell is expanding the asterisk wildcards in your command, so the actual command that the Perforce server is seeing is:
`p4 move filea_mk1.txt fileb_mk1.txt ./mk1/...`
and that command has three file-spec arguments, rather than the expected two file-spec arguments, hence the Usage: message that you receive.
By using operating-system filenames (*_mk1*.* and ./mk1/...), you are providing the file-spec arguments in what Perforce calls "local" syntax.
But this causes your operating system shell to think it should expand the wildcards, when what you want is to have the Perforce server expand the wildcards.
You can try using different quoting strategies for your arguments, to defeat that local wildcard expansion, but this is a situation where you can benefit from using one of the other forms of file-spec syntax, either "client" syntax" or "depot" syntax.
For example, suppose that your client root is actually located in a section of the depot that begins with the path //depot/projects/project1/main/.
Then, you could specify your command as:
`p4 move //depot/projects/project1/main/*_mk1*.* //depot/projects/project1/main/mk1/*_mk1*.*`
In this case, these file-spec arguments will not be seen as syntax that your operating-system shell should expand, so it will leave the arguments alone and pass them unaltered to the server, so that the Perforce server can perform the wildcard expansion, rather than allowing your shell to perform the wildcard expansion.
Note that I also re-specified your wildcard expansion slightly. The Perforce move command, like the integrate command and several other commands, is typically happiest if the "wildcards on the left side" match up with the "wildcards on the right side", so that when it is constructing new destination file names for the files being moved, it can replace the wild-carded elements 1-1 with the wild-carded elements from the source file names.
I have distributed my computing to many platforms so I cannot use fullpath but instead relative like $HOME.
Code
filename=strcat('$HOME/Images/',num2str(item);
save(strcat(filename,'.mat'),'masi');
saveas(her, strcat(filename,'.png'));
Output
Error using save
Cannot create '777.mat' because '$HOME/Images' does not exist.
Error in masiCool (line 98)
save(strcat(filename,'.mat'),'masi');
Backward flash \$HOME does not work neither.
How can you have $HOME in Matlab's save/saveas?
Environment variables (such as $HOME) are not automatically parsed by MATLAB. In general, if you need the value of an environment variable, you can use getenv.
homedir = getenv('HOME');
Alternately, on *nix, you can actually just use the tilde (~) to represent the user's home directory in a filepath.
folder = '~/Images';
However, I typically just rely upon the Java to get the user home directory for me since it will work properly on any platform.
homedir = char(java.lang.System.getProperty('user.home'));
Then, use fullfile to concatenate the path you want onto the user's home directory.
filename = fullfile(homedir, 'Images', sprintf('%d.mat', item))
NOTE: If you are wanting to do this on an HPC or some instance of MATLAB that is not using the JVM. The getenv option is best. On Windows, you would want the HOMEPATH variable rather than HOME.
Try full path instead of using $HOME. $HOME is a system command and it is not recognizable in Matlab.
Use \home\YOUR_USER_NAME instead of $HOME.
TIP: In case you have to use a system command inside Matlab, system() is a useful function.
I'm having trouble correctly using the /GROUP="" command line parameter for my installation when called by a parent installation. What exactly should be specified and what is the "base"?
For example, the parent installer determines the full path to where the start menu entries will be. If this path is passed to /GROUP, it gives an error about invalid characters; namely, :.
I know the parameter supports use of expand prefix, but does this mean the parent installer must determine which constant to "expand" rather than simply passing the already determined path?
UPDATE:
It seems I was mistaken in thinking I could select the "base" of the menu entries (all users, local). It seems this is done automatically, but perhaps this is a more complete example:
An older Wise installation determines the filesystem path where the menu entries will be installed. It then executes my installation and passes that path using /GROUP. This is where my problem arises because /GROUP expects only a directory, not a full path.
The /GROUP="x" parameter specifies the value for the {groupname} constant, eg. it should be of the form /GROUP="MyApp". It should not contain a path, or at least if it does contain one it should be a very shallow relative path such as /GROUP="MyCompany\MyApp".
If you are passing the parameter from a parent Inno install script and you want the child install to install icons into the same group as the parent then you should use /GROUP="{groupname}".
In all cases, the "root" of the path will automatically be chosen by Inno to be either {commonprograms} or {userprograms} depending on the PrivilegesRequired setting of the install script being run.
Note that if you are running the installer as part of an automatic update to an already-installed application, you should not pass the parameter at all. Inno will remember the user's previous selection and use this by default; in fact it's strongly recommended to not offer the user a chance to change this during interactive upgrades by setting the following:
[Setup]
DisableDirPage=auto
DisableProgramGroupPage=auto
Currently, running prove with TAP::Formatter::JUnit supports an environment variable PERL_TEST_HARNESS_DUMP_TAP that sets a path where a directory t/ will be created, and for each test file x, new files named x and x.junit.xml are created in the directory. I would like to be able to format the output filenames in a different way. Is there any way to do this?
A quick look at TAP::Formatter::JUnit::Session says "no" - there is no way to modify it without writing your own formatter, deriving off TAP::Formatter::JUnit and overriding its open_test method to point to your own session, which would, in turn, be derived off TAP::Formatter::JUnit::Session with its dump_junit_xml overridden to do what you want - but now you're modifying the entire dump (and thus don't need to rely on that environment variable if you prefer).
I guess all that derivation is a way, though probably not the way you thought/were hoping.