I am attempting to use the SVN_Load_Dirs.PL script file (https://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/) to attempt to merge a platform drop.
However, I can't get the --glob_ignores flag to behave as I'd expect, and I know so little perl that I can't dig into the script to understand why. The format I am using is:
--glob_ignores=*.jazzignore
Where I want to ignore all .jazzignore files (although I am fine with anything with "jazzignore" in either the extension or name being ignored. I've looked for examples but can't find any actual usage of this flag anywhere. What I am looking for is a way to ignore all .jazzignore files and a few entire directories (like jazz5 for an example)
I assumed the flag would then be --glob_ignores="*.jazzignore *.jazz5" but that doesn't appear to be working.
It turns out that the script was failing silently because I was running it from a windows cmd (and therefore never getting to the flag option). Apparently there are some issues running it this way and it was designed to be run from a linux command line. After switching it works perfectly.
Related
I've added an option to copy a proper UNC path to the context menu of all directories via PowerShell.
Edit:
I didn't mention that I'm actually using two different keys: One to copy the UNC of the current directory, and one to copy it from a different directory. I didn't think it would make a difference, but it does.
End Edit
Currently, the key value is as follows:
powershell.exe -WindowStyle Hidden -Command . <path I have to censor>\Save-To-Clipboard.ps1 \"%L%\"
Expected behaviour:
The PowerShell script is run quietly.
Actual behaviour:
A PowerShell Window pops up and closes itself.
The same thing happens with cmd.
I've tried using a VBS wrapper as well, but it needs the current path as an argument, which I can't figure out how to do. Simply putting it after the filename as you would in the command line results in the error:
This file does not have an app associated with it for performing this
action. Please install an app or, if one is already installed, create
an association in the Default Apps settings page.
Key value here:
<path I have to censor>\ClunkyWrapper.vbs \"%L%\"
Admittedly, this is my first time running a command from a registry key, and I can't seem to find any resources about this topic. (I might just not know what exactly to google for.) So I would be thankful for more general information on how to run commands from registry keys as well.
Okay, I found a way.
First of all, apparently whether you need to use %L% or %V% depends on the key. I can't tell you why, unfortunately.
That solves the error message of the VBA script, but it still wouldn't run like this.
So I then used wscript.exe, and it finally worked.
wscript.exe <secret path>\ClunkyWrapper.vbs "%V%"
I have a collection of scripts which was created with AutoHotkey v1. I would like check to see if these scripts are compatible with the upcoming AutoHotkey v2.
According to the changelog, there have been several changes in AutoHotkey v2 which break backwards compatibility with v1. This has made it hard to tell which scripts need updating without thorough testing.
Even after determining that a script needs to be updated, it can be even more difficult to determine which parts of the scripts need updating.
How can I check if a script needs to be updated for compatibility with AutoHotkey v2?
From what the notes suggest, you will be best piping the output to a file and checking the result.
https://autohotkey.com/docs/Scripts.htm#ahk2exe
When parameters are passed to Ahk2Exe, a message indicating the success or failure of the compiling process is written to stdout. Although the message will not appear at the command prompt, it can be "caught" by means such as redirecting output to a file. [v1.0.43+]
Ahk2Exe.exe /in MyScript.ahk > MyScript.txt
To make things simpler, you could pipe all to the same file.
Ahk2Exe.exe /in MyScript.ahk >> Scripts.txt
I am not sure this is clear to me and if is neat for my system. I'm aware of the ~/.zhrc file where I can store alias and paths, but today after installing node via brew I was asked to put this: export PATH="$HOME/.npm-packages/bin:$PATH" in my ~/.bash_profile file, which it doesn't exist, thus in my effort to keep my system clean I putted it in the former file but emacs complaint. Now, I removed it and putted it, after creating, in the ~/.bash_profile. Is that OK to keep both in the home directory?
You need to provide the exact wording of whatever error or warning message you
get from emacs to ensure accurate or better answers. However, I will make a
guess and assume the warning you are getting is from the exec-path package.
This package has a check, which you can disable, that looks to make sure you
have variables defined in the correct init file.
In general, most shells support two types of configuration files
Startup or Login init files
Interactive shell init files
The difference is how often or when the files are sourced (loaded). To
understand the difference, you really need to understand when a shell is run and
the relationship between each shell. I'll try to give a vary high level
explanation, but you really should read the manual page for the particular shell
you are using.
Think of your environment as a tree of shell processes. When you login to the
system, a login shell is created. This shell will be the parent of all the other
shells you create. Each time you run a command, it is executed in a new shell
(this isn't 100% accurate, but is accurate enough to explain the main
points). So when you open a terminal, it runs another shell which is a child of
your login shell. When you execute various commands, the system creates a new
shell and runs that command inside the shell. These are all children of your
parent login shell. Some shells only exist for a short period of time (as long
as it takes to execute the command), others may last for hours, days or possibly
weeks (such as the shell that emacs is running in).
The important point to keep in mind is that child shells inherit various
settings from the parent shell. The idea of the 'export' command you will see in
front of some variables is actually a command to the shell telling it to export
the variable to child shells. For example, if we have a line like
export PATH=/usr/local/bin:/usr/bin:/bin
what we are really doing is
PATH=/usr/local/bin:/usr/bin:/bin # set the variable
export PATH # make it available in child shells
We don't always want variables to be exported as some variables need to be reset
in the child shell itself. For example, the variable holding the prompt string.
It would not work to have this variable only defined in the login parent shell
if you want the prompt to have dynamic components, such as the current
directory, date or time. We want these types of variables to be defined in each
shell when it is created.
To handle this, shells have the two different init files. The login init files
are only sourced for the parent shell and are particularly useful for setting
variables that will be common to all child shells. the per-shell init files are
sourced for every new shell and are best used for setting things which need to
be updated or changed each time a shell is started. There are also other shell
configuration files which can be used for other special purposes, such as when
you log out or log off a system, or to just put alias definitions in etc.
Once upon a time, it made a big difference where you put your variables as there
was a performance hit when sourcing these init files. If the per-shell init file
was too large and consumed too many resources, the whole performance of your
environment could be affected. This is largely less of an issue these days due
to increased processing speeds. Unfortunately, because many people didn't
understand the role and relationships between the different shell configuration
files, there is lots of incorrect or misleading information out there regarding
where values should be set. People often advise setting variables in (for
example) bashrc when they should be set in the bash__profile=. The confusion is
partly caused by the fact you can add a variable to bashrc and it will work when
you test it (usually because your test involves forking a new child shell) and
putting it in your bash_profile will only work after the next login.
There are also some platform differences which make things a little less
clear. For example, under OSX, there is actually a special file in the /etc
directory where you should add additional path components (I'm not on a mac just
now, but it is something like /etc/paths or a per path component file in
/etc/path.d). This is done so that you have a global place to set paths which
will ensure desktop processes, such as the dock, which do not run as a child
process of your login shell, are able to be set.
As a general rule, most variables can go in the login profile, with the
exception of variables relating to the prompt or other variables which have a
dynamic content i.e. content which changes depending on time, directory
location or other tracking of interactive actions which are specific to a shell
instance.
Setting of the path (noting OS differences as described above) should go into
the profile or login configuration file. Under bash, this is .bash_profile and
under zsh, it is typically .zprofile. As bash has become the most common shell,
documentation etc often advises adding things to .bash_profile. If your running
zsh, then add the same information using .zprofile.
As you have said you don't have a.bash_profile, but you do have a zshrc file, I
am assuming you are running zsh rather than bash as your login shell. This being
the case, you need to add that path setting to .zprofile in your home
directory. The exec-path package is complaining because you added it to
zshrc/bashrc, which are not the correct place to set path variables. If your
running under OSX, you really need to add the path to the correct file in /etc
(you will need to check the OSX documentation as I cannot remember the precise
filename).
I got a problem when executing batch file commands through matlab. This batch file includes commands to run simulations in Adams. When I execute the batch file directly from DOS window, it works well. But if I use matlab to execute it (using command dos()), it gives error saying 'cannot check out the license for Adams'.
This confuses me: if the license is incorrect, it should not work no matter I execute the batch file directly in DOS or ask MATLAB to execute it. I also tried to execute other DOS commands through matlab using dos() and it worked well.
Does anyone know what the problem may be?
Such issues are commonly caused by some environment variables being changed or cleared by MATLAB. I have very similar experience on Linux and Mac OS X, where this causes havoc when using system or unix.
In Unix-like systems, MATLAB is started from a shell script where all of this happens. So you can either incorporate missing variables there or in the .matlab7rc.sh in your home directory (the latter is preserved when you upgrade MATLAB and it is much easier to use). I won't go into all the Unix details here.
An alternative workaround is to explicitly set those variables when you issue a system command (e.g. system('export variable=value ; ...')). It is quite a bit of work, but you can then use that MATLAB code on different computers with ease.
On Windows, I'm not completely sure about the exact location of the corresponding files (and whether MATLAB starts in quite a similar way as on Unix). But if they exist, you can probably find it in the MATLAB documentation.
Anyhow, the alternative fix should work here as well.
First you need to diagnose which system variables you need (likely a PATH or anything that has a name related to Adams).
To do so in Windows, run set from the Windows command prompt (cmd.exe) and from within MATLAB. Whatever differs in the output is a possible suspect for your problem.
To inspect just a single variable, you can use the command echo %variablename%.
I will assume that you have found that the suspect environment variable is missing and should be set to value.
The workaround fix is then to run your command in MATLAB as system('set suspect=value & ...') where you replace ... with your original command.
I'm currently trying to get this script to work:
https://github.com/mj41/auto-unrar/blob/master/bin/unrar2.pl
The only problem is that I get the following error:
Entering directory 'Series'
Entering directory 'Series/SerieName'
Entering directory 'Series/SerieName/Season2'
Entering directory 'Series/SerieName/Season2/SerieNameS02E21.720p.HDTV.X264-DIMENSION'
Entering directory 'Series/SerieName/Season2/SerieNameS02E21.720p.HDTV.X264-DIMENSION/Sample'
Can't call method "List" on an undefined value at unrar2.pl line 973.
This line is rar_obj->List();
$rar_conf{'-verbose'} = $rar_ver if $rar_ver;
my $rar_obj = Archive::Rar->new( %rar_conf );
$rar_obj->List();
my #files_extracted = $rar_obj->GetBareList();
This is an old script, 3-4 years old and I changed a little like SHA1 to SHA and use Filesys::DfPortable; to Df
Does anyone know how I can fix this error :)?
EDIT:
I contacted the developer and he told me I needed to install a program that can handle rar commands. So how would I do that. I can't seem to be able to install unrar.
EDIT2:
What my problem is now, 2 of the 3 unrar packages aren't in my architecture, armhf.
To install the script yourself::::::::::::
https://github.com/jorricks/UNRAR
You need to pass the -archive parameter into the call to new() otherwise how will $rar_obj know which file it is supposed to be looking at?
I can't seem to be able to install unrar
That's not a particular good explanation of your problem. What did you try? What unexpected behaviour did you see?
From the tags on your question, it looks like you're running Debian. What do you see if you run sudo apt-get install unrar?
Update: My first comment was based on the code extract that you showed us. Looking at the full program code, I can see that %rar_conf has other values set in it (including the -archive option) before the section of code you gave us.
Looking at the source of the Archive::Rar module, it seems to assume that the program to use for dealing with the archives is called rar. So 7-Zip is not going to work.