I use Stata 14.1 on Windows 8.1 and moved my personal .ado files to GitHub repositories. This put foo.ado in "C:/Users/Richard/Documents/GitHub/foo/", bar.ado in "C:/Users/Richard/Documents/GitHub/bar/", and so on.
I added the GitHub root directory to adopath with adopath + "C:/Users/Richard/Documents/GitHub/", but Stata did not search "foo", "bar", and other sub-directories for .ado files. I fixed this by adding the foo.ado repository with adopath + "C:/Users/Richard/Documents/GitHub/foo", and so on.
I expected Stata to search "C:/Users/Richard/Documents/GitHub/" recursively because it does so for BASE, SITE, and PLUS. Is recursive searching limited to the default adopath directories?
To be fair, it isn't difficult to add a ten directories to adopath, but I want to follow best practices. I can't find much about adopath other than help adopath and this 1996 FAQ.
Stata doesn't exactly recursively search BASE, SITE, and PLUS. It searches each directory, and within the directory, will search in exactly one subdirectory having as its name the first letter of the command being searched for.
Within PERSONAL, I created the subdirectory f and placed within it foo.ado. When I typed the command foo into Stata's Command window, Stata found foo.ado and ran the program within.
This doesn't directly solve your problem, but it does show that Stat treats PERSONAL consistently with the other directories, reducing the likelihood of convincing StataCorp to implement your suggestion, but confirming that your workaround seems to be "best practices" such as they are.
On my Mac, I renamed the directory f to gnxl and then, in a terminal window
cd ~/Library/Application Support/Stata/ado/personal
ln -s gnxl/foo.ado .
after which, having exited and relaunched Stata, the foo command performed as expected. Perhaps this points a direction for you, with some automation to generate the symbolic links as new ado files are created in your repository. I don't know enough GitHub to know if that is possible within its framework.
Related
I have a C# solution with projects that are not all in folders under the *.sln directory. If I make a change in a file from such a lateral project and then try to commit the solution (as shown in picture below) these changes are not listed, but only those made in projects under the solution directory.
My experience is that the property to see differences from all projects, independently from their physical locations, is sometimes present. Sometimes not, however, and I do not see why. Where are the configuration data for VisualHG in VS 2017 telling it which projects to consider (when pushing 'commit solution')?
I do not know how to find these settings, either (to my experience, what you have described, happens really), but I can propose a workaround.
Namely, you can simply create a batch file (something like my_batch_commit.bat) where you will have a list of all local folders with your partial HG repositories, e.g
cd C:\MyProjects\Project_A
thg commit
cd C:\MyProjects\Project_B
thg commit
cd C:\MyProjects\Project_C
thg commit
REM ...
the folders are those where the corresponding .hg directories lie. thg.exe is the name of the Tortoise HG GUI (must be retrievable via PATH, but if Tortoise HG is correctly installed, this is fulfilled automatically).
If you now execute the batch file, you will be presented with a number of THG instances, one for each HG repository, so you can deal with them one after another.
I'd like to add a directory containing .ado files to the ado-path. This directory contains several subdirectories, corresponding to different projects. The .ado files are in these subdirectories.
However, when I type adopath + directory, commands in the .ado files are not recognized by Stata. I need to enter adopath + directory/subdirectory for each subdirectory. Is there a way around it?
Stata has a rule that in addition to the directories (etc.) explicitly named in the adopath, it will also look off those in subdirectories named by an individual letter for programs whose names begin with that letter.
Thus suppose you are invoking a command whatever and your named directories include c:\ado\plus. Stata's searches will include c:\ado\plus\w if that exists and a program file has not yet been found.
However, Stata doesn't promise to search in all subdirectories and it will pay attention to the initial letter of the program name.
Having .ado files specific to a project would best be accommodated by changing to the directory involved while working on that project. If you prefer not to do that, then you need to name specific directories fully if they don't match your adopath as extended by this single letter rule.
This is a matter of personal style, but I have never thought of any ados I wrote as specific to a particular project. Do-files yes, but not ados. But your project do-file might start with additions to the adopath and finish with reversing those.
So I am running into an issue when I go to build my projects using tfs build controller using the Output location "AsConfigred" it will not detect my unit tests. Let me give a little info on my setup.
TFS 2013 Update 2, Default Process Template
Here is a few screenshots that can hopefully help fill in what I can't in typing. I am copying my build out to a file share on our network so that we can use other utilities use the output. I don't want to use "PerProject" or "SingleFolder" because they mess up the file structure we have configured (These both will run the tests). So i have the files copy to folder names "SingleOutputFolder" which is a child of the DropLocation. I would like to be able to run from the drop folder or run from the bin folder for each of my tests (I don't care which). However it doesn't seem to detect/run ANY of the tests. Any help would be greatly appreciated. Please let me know if you need any additional information.
I have tried using ***test*.dll, Install\SingleFolderOutput**.test.dll, and $(TF_BUILD_DROPLOCATION)\Install\SingleFolderOutput*test*.dll
But I am not sure what variables are available and understand where the scope of its execution is.
Given that you're using Build Output location set to AsConfigured you have to change the default values of the Test sources spec setting to allow build to find the test libraries in the bin folders. Here's an example.
If the full path to the unit test libraries is:
E:\Builds\7\<TFS Team Project>\<Build Definition>\src\<Unit Test Project>\bin\Release\*test*.dll
use
..\src\*UnitTest*\bin\*\*test*.dll;
This question was asked on MSDN forums here.
MSDN Forums Suggested Workaround
The suggested workaround in the accepted answer (as of 8 a.m. on June 20) is to specify the full path to the test projects' binary folders: For example:
C:\Builds\{agentId}\{teamProjectName}\{buildDefinitionName}\src\{solutionName}\{testProjectName}\bin*\Debug\*test*.dll*
which really should have been shown as
{agentWorkingFolder}\src\{relativePathToTestProjectBinariesFolder}\*test*.dll
However this approach is very brittle, for the following reasons:
Any new test projects you add to the solution will not be executed until you add them to the build definition's list of test sources:
It will break under any of the following circumstances:
the build definition is renamed
the working folder in build agent properties is modified
you have multiple build agents, and a different agent than the one you specified in {id} runs the build
Improved Workaround
My workaround mitigates the issues listed in #2 (can't do anything about #1).
In the path specified above, replace the initial part:
{agentWorkingFolder}
with
..
so you have
..\src\{relativePathToTestProjectBinariesFolder}\*test*.dll
This works because the internal working directory is apparently the \binaries\ folder that is a sibling of the \src\ folder. Navigating up to the parent folder (whatever it is named, we don't care) and back in to \src\ before specifying the path to the test projects binaries does the trick.
Note: If you have multiple test projects, you add additional entries, separated with semicolons:
..\src\{relativePathToTestProjectONEBinariesFolder}\*test*.dll;..\src\{relativePathToTestProjectTWOBinariesFolder}\*test*.dll;..\src\{relativePathToTestProjectTHREEBinariesFolder}\*test*.dll;
What I ended up doing was adding a post build event to copy all of the test.dll into the staging location folder in the specific build that is basically equivalent to where it would go on a SingleFolder build and do that on each test project.
if "$(TeamBuildOutDir)" == "" (
echo "Building Interactively not in TFS"
) else (
echo "Building in TFS"
xcopy "$(TargetDir)*.*" "$(TeamBuildBinaries)\" /Y /E /S
)
MSBUILD parameter in the build def that told it to basically drop in the folder that TFS looks for them.
/p:TeamBuildBinaries="$(TF_BUILD_BINARIESDIRECTORY)"
Kept the default Test assembly file specification:
**\*test*.dll
View this link for the information on the variable that I used and what relative path it exists at.
Another solution is to do the reverse.
Leave all of the files in the root so that all of the built in functionality works. There is more than just test execution in there. What about static code analysis, impact analysis..among others. You would have to do something custom for them all.
Instead use a pre-drop powershell script to create your Install arrangement from the root files.
If it is an application then you can use the _ApplicationFolder Nuget package to create an _PublishApplications folder same as you get for web applications.
I'm just getting my feet wet in C++ using the Stanford CS 106B lectures available online. The assignments have the students use some custom libraries which are available for download online, although the installation instructions are gone.
While I can do the assignments in Xcode using a pre-built blank project which includes the relevant files and source trees set up, I also have TextMate on hand and thought I'd like to try coding with it, since I liked using it a lot for coding LaTeX. So far so good.
The first program I'm trying to run (a very simple ten-line program) contains an # include "genlib.h" in the first line. I have the genlib.h file, but can't seem to get either of the following to work:
Add the path to the relevant file in TextMate: When I try to add the path to the folder on my desktop (/previouspathinthelist:/Users/me/Desktop/C++\ libraries) where the file lives I get an error: /Users/me/Documents/c++ programs/powertab.cpp:9:20: error: genlib.h: No such file or directory even though the file is right there! (Maybe I should note here that the file to be imported and the program file are in two different folders).
Add the file to one of the other paths: I can't move the files using mv in terminal to usr/bin, usr/sbin, etc. because it says I don't have the proper permissions.
Is there something I'm doing wrong in setting my path to my folder in Documents? There aren't any spelling mistakes or anything since the path came straight from get info in the finder. I know this is a programming forum and not a TextMate support forum, but I thought it'd be good to know where people generally put these kinds of files on their systems.
Just put the file in the same directory as your other source files.
#include "filename"
searches the source directory first, whereas
#include <filename>
only searches the include file path.
The reason why /previouspathinthelist:/Users/me/Desktop/C++\ libraries doesn't work probably has to do with the space in the file name. It is quite possible that a backslash is not the right way to quote the space in the tool you're using. Many tools from the C/unix tradition deal rather badly with pathnames that contain space (even though the Unix kernel itself has no such problem); often you'll find that there is no single amount of quoting that will simultaneously satisfy all the tools and subsystems that use some setting. Better to avoid spaces in filenames entirely when you're doing development.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
Possible Duplicate:
Code won’t run. [not]
I have written and compiled a program and i want to make it so that from shell i can just type programname to make it run instead of going to the directory the the program is in and typing ./ before the program name. If this is possible please let me know.
You must learn the ways of the PATH if you're to come with me to Alderaan.
You should add the directory where your compiled program is to your PATH.
For example if you are inside the /home/jimmy/cpp directory
type (leading $ is the prompt)
PATH=$PATH:`pwd`
$myprog
Read about exporting variables and the bashrc file to make this change permanent. (assuming bash as your shell)
A detailed discussion of why putting . (current directory) in the PATH is a bad idea.
Lets say you're being attacked by an adversary on your machine.
He authors a malicious program, and puts it in a directory, hoping that you'll stumble on it eventually. To increase his chances, he names it something common like mv.
If you have added . to the beginning of your path, and happen to be in the right directory when you type mv onefile twofile... then the local mv (./mv) gets run instead of the mv command we're all used too! This happens because . is in your path, and the local mv will be found before the /usr/bin/mv. Suddenly, your user account or the entire machine may be horribly compromised.
(note: mv might be one of the built-in commands, and immune to this. Not sure... but the principle is solid)
So, you learn the lesson, and now put . at the end of your path, so that all "official" directories will be searched before the local directory.
But the attacker is now on to you! Instead of the program mv, he creates in a program mc, which is a common typo for mv. Again, you intend to type mv onefile twofile, but make a simple typo to mc. Now all the "official" directories are searched, the program mc is not found, and finally it is found in the local directory. Malicious code is run, and again you lose.
The lesson is that your PATH should only cover known-good software, and since your current directory changes frequently, you never know exactly what software is there, and should never run it unless you're very explicit about it with the ./ prefix (eg. > ./IMeanToRunThis)
http://ss64.com/bash/alias.html
e.g.
alias progname=/path/to/program/progname
Personally, I use $HOME/bin as a personal collection point for utilities I wrote but that won't be of use to all users. Otherwise, /usr/local/bin is often the right place for locally written programs that are of use to all users. In any case, I have verified that the latter place was on my path and added $HOME/bin as well.
Unless you really are an installer, it is probably not a good idea to go dropping programs into /bin or /usr/bin despite temptation. That would be the moral equivalent of putting your programs in C:\Windows or C:\Windows\System32. It is effectively never the correct answer.
Learning more about the PATH environment variable and how the shell searches for programs to run is definitely recommended. Also, as pointed out in another comment, just don't add . to your PATH because it will come back to haunt you at some point.
Edit: Incidentally, I do a very similar thing on my Windows boxen. I always create a sibling to C:\Program Files named C:\Programs. In there, I make a folder named bin and add that to the system path. I use C:\programs\bin much like I use $HOME/bin on a *nix box, and put any hand-installed (i.e. no real Windows installer was used) programs or stuff ported from *nix that can't tolerate spaces in its path in there in other folders such as C:\Programs\mingw, C:\programs\MSYS, or C:\programs\cygwin.
Any small utilities primarily used from the command prompt usually end up in C:\programs\bin, but for anything I'm seriously planning to use on more than one PC I generally create a real Windows installer with InnoSetup and let it get installed in C:\Program Files.