is the clearcase path syntax is universal one.
my_source.c##\main\10.1_bugfix\another_branch\0
is this path is standard one?
I invoked the following in emacs and it is working. how does emacs diff understand this path. somehow clearcase informs operating system how to interpret that path. or emacs-diff know of this path syntax?
$ diff my_source.c##\main\10.1_bugfix\another_branch\0 my_source.c
This is an extended path.
It is working with dynamic views, which give access to the branches and versions of an element.
See "Base ClearCase path meaning".
In your case, you access the version 0 of the branch main\10.1_bugfix\another_branch.
See also the IBM technote "About the version-extended path" for an example, and pathnames_ccase for the doc:
You can add characters to the end of a relative or full path name, turning it into a VOB-extended path name.
VOB-extended path names that specify versions of elements are the most commonly used; they are called version-extended path names.
Related
I'm trying to install a grunt template on my computer but I'm having issues. I realized that perhaps something different is happening because of the path given by the Grunt docs, which is
%USERPROFILE%\.grunt-init\
What does that . mean before grunt-init?
I've tried to do the whole import manually but it also isn't working
git clone https://github.com/gruntjs/grunt-init-gruntfile.git "C:\Users\Imray\AppData\Roaming\npm\gru
nt-init\"
I get a message:
fatal: could not create work tree dir 'C:\Users\Imray\AppData\Roaming\npm\.grunt-init"'.: Invalid argument
Does it have to do with this /.? What does it mean?
The \ (that's a backslash, not a slash) is a directory delimiter. The . is simply part of the directory name.
.grunt-init and grunt-init are two distinct names, both perfectly valid.
On Unix-like systems, file and directory names starting with . are hidden by default, which is why you'll often see such names for things like configuration files.
The . is part of a directory name. Filenames can contain . . The \ is a separator between directory names.
Typically, files or directories starting with . are considered "hidden" and/or used for storing metadata. In particular, shell wildcard expansion skips over files that start with ..
For example if you wrote ls -d * then it would not show any files or directories beginning with . (including . and .., the current and parent directories).
Linux hides files and directories whose names begin with dot, unless you use the a (for "all") option when listing directory contents. If this convention is not followed on Windows, your example is probably just a carryover.
It may well be something behind the scenes (later) expects that name to match exactly. While I like things, installers, for example, to just do what I said, I realize that keeping default value is the most tested path.
Directories starting with a dot are invisible by default on xNIX systems. Typically used for configurations files and similar in a users home directory.
\ before " has a special meaning on windows, the error is because windows won't let you create a file containing " as part of its name.
I'm having trouble installing Homebrew, and it looks like the problem (invalid byte sequence in UTF-8 (ArgumentError) error message) is due to a fault in my PATH. when I run echo $PATH, I get the following (be sure to scroll to the far right in the code block below to see the fault):
/usr/local/mysql/bin:/opt/subversion/bin/:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:PATH=/usr/local/share/python:$PATH:PATH=/usr/local/share/npm/bin:$PATH:export PATH��:/usr/local/git/bin
I have no idea where those strange characters just before the /usr/local/git/bin path are coming from. I'm using bash (tried zshell, same problem). I can't find where this coming from. my .bash_profile file looks clean, too.
Examine your ~/.profile, ~/.bash_profile, and ~/.bashrc files. It is also possible that these values are being set in /etc/profile or other system-wide files, but the nature of the errors is such that I would assume they are the result of your own manual edits of your personal files. You're the best judge to decide what you may have changed and when.
Look for entries such as the following:
PATH='/usr/local/share/python:$PATH'
PATH='PATH=/usr/local/share/npm/bin:$PATH'
PATH='export PATH��:/usr/local/git/bin'
They should instead look like
PATH=/usr/local/share/python:$PATH
PATH=/usr/local/share/npm/bin:$PATH
PATH=$PATH:/usr/local/git/bin
# Not strictly necessary -- PATH is already exported
export PATH
See a pattern? These all add a value to PATH by setting it to prefix:$PATH or $PATH:suffix where the new prefix or suffix is the directory where you have installed a local package. Whether the new value should be a prefix or a suffix is probably of little consequence -- except if you are trying to override a system version (say, your /usr/local/git is installed because /usr/bin/git is too old -- then, it's important that your local version comes first in the PATH). There is also a minuscule speed difference the first time you run a command; the shell has to look in more places before finding it if it's at the end of the PATH.
The difference in quoting is significant -- PATH=$PATH:suffix expands to the old value of PATH with :suffix added on, whereas PATH='$PATH:suffix' replaces the old value of PATH with the literal string $PATH with :suffix added on. You're lucky none of this has ended up replacing your original PATH completely, which would render your shell by and large inoperable (at least until you discover that you have to use /bin/ls instead of just ls).
I have added a include directory in my home directory. I can run "ls -l ~/include" from the build directory.
I have added that directory in both "Header Seach Path" and in "User Header Search Path". In both places I have tried with both non-recursive and recursive.
But xcode 4.5.1 can not in any situation find the first stated header file.
It is stated in source code calls.m as:
#include <directory/file.h>
I get a "Lexical or Preprocessor issue 'directory/file.h' file not found."
But when running xcodebuild from cli it has no problems what so ever to build the source.
I have tried many of the suggestions found on internet
Putting a include in /usr/ om my drive
Adding a index to the project, adding files with no copy and no "Add to target" marked.
Restart xcode.
Specifying all specific paths.
But still no go.
What is the problem. Bug´s in xcode?
I just had a similar issue, and it was because there were spaces in the path which I defined for the Header Search Path. For example, I was defining the following as a search path:
$(SRCROOT)/Frameworks/Headers
which was being expanded out to the following:
/Users/skoota/Documents/Xcode Projects/My App/Frameworks/Headers
as you can see, there are spaces within the path (which are not immediately evident, as you are using the $(SRCROOT) variable) and the compiler doesn't particularly appreciate the spaces. I solved this problem by changing the search path to this:
"$(SRCROOT)"/Frameworks/Headers
(note the quote marks around $(SRCROOT) which escapes the spaces). This now expanded out to:
"/Users/skoota/Documents/Xcode Projects/My App"/Frameworks/Headers
which works perfectly, although looks a bit odd with the embedded " marks. This took me a while to figure out, so hopefully it helps!
This usually happens if there are spaces in your directory's path. To overcome this problem, use double quotes around the path.
Suppose you want to use your project directory, then you should use: $PROJECT_DIR. Enable recursive if you want to search within the folders as well. Alternatively, you can use $(SRCROOT)
I am invoking VSDBCMD.EXE in my build process template, there is a custom setvar parameter that requires a reference to the current source directory, passing this path has become an unexpected challenge.
I've tried using relative paths and $(SourceDirectory) to no avail (it remains as the literal string "$(SourceDirectory)" when I see the debug output), the parameter needs an absolute path.
Is there any way to get the absolute path for the current source directory when the script runs?
In the DefaultTemplate build workflow there is a variable called SourcesDirectory that contains the absolute path.
If you pass it to an InvokeProcess you just type the variable name in the activity property, no $() around it.
It might be worth checking out this resource, where author makes use of ConvertWorkspaceItem within his build in order to pass in a string the disk location of a know target in source control
So currently I have included the following in my .bashrc file.
export RUBYLIB=/home/git/project/app/helpers
I am trying to run rspec with a spec that has
require 'output_helper'
This file is in the helpers directory. My question is that when I change the export line to:
export RUBYLIB=/home/git/project/
It no longer finds the helper file. I thought that ruby should search the entire path I supply, and not just the outermost directory supplied? Is this the correct way to think about it? And if not, how can I make it so RUBY will search through all subdirectories and their subdirectories, etc?
Thanks,
Robin
Similar to PATH, you need to explicitly name the directory under which to look for libraries. However, this will not include any child directories within, so you will need to list any child sub-directories as well, delimiting them with a colon.
For example:
export RUBYLIB=/home/git/project:/home/git/project/app/helpers
As buruzaemon mentions, Ruby does not search subdirectories, so you need to include all the directories you want in your search path. However, what you probably want to do is:
require 'app/helpers/output_helper'
This way you aren't depending on the RUBYLIB environment variable being set a certain way. When you're deploying code to production, or collaborating with others, these little dependencies can make for annoying debugging sessions.
Also as a side note, you can specify . as a search path, rather than using machine-specific absolute paths.