I'm attempting to pass gulp.src an array of files that I want it to deal with. This is the array as it stands.
['bower_components/jquery/jquery.js',
'bower_components/superscrollorama/js/greensock/TweenMax.min.js',
'bower_components/superscrollorama/jquery.superscrollorama.js' ]
I'm finding though that gulp.src doesn't seem to like that and the third element doesn't make it through into the end destination.
I've found that everything works fine when I introduce some wildcard characters like this:
['bower_components/**/jquery.js',
'bower_components/**/js/greensock/TweenMax.min.js',
'bower_components/**/jquery.superscrollorama.js' ]
But why? Something to do with the way globbing works? I've googled but can't find out.
Maybe this isn't the intended purpose of globbing but it doesn't make sense to me that it should work this way. Can anyone shed some light?
When you pass in an array of full paths, each file is processed independently. The globbing doesn't know where the root of the path is (in fact, it guesses based on the first glob). Therefore, each file is rooted in the folder it contains, and the relative path is empty.
However, there is an easy solution. Pass an object with the key base as the second argument to gulp.src, and everything will have the correct relative path:
return gulp.src(['bower_components/jquery/jquery.js',
'bower_components/superscrollorama/js/greensock/TweenMax.min.js',
'bower_components/superscrollorama/jquery.superscrollorama.js' ],
{base: 'bower_components/'})
.pipe(...);
Related
I'm trying to get an array containing the full current directory path in zsh. I'm currently using
local pwd="${PWD/#$HOME/~}"
pwd_list=(${(s:/:)pwd})
Which works except for one problem, it treats the starting / as a directory split too. I'd like my array to be like
/
usr
lib
php
instead of
usr
lib
php
I can see 2 ways of doing this but I'm unaware of how to do either in zsh. The first idea is to simple do a push and force a new element to the beginning (after the split).
The second, would be to alter the split to ignore the first / when parsing.
How can I resolve this to get an accurate directory path with minimal overhead into an array?
do you really need the first /? Assuming you're using a script to use the results of that, can't you just cd / to just start from there?
Anyways... is this what you want?
local pwd="${PWD/#$HOME/~}"
pwd_list=(${(s:/:)pwd})
pwd_list=('/' $pwd_list)
I think you're thinking about it slightly wrong. If you split "/usr/lib/php" on "/", you should get four elements, the first of which is an empty string. If you join those array elements back together with "/", you get the original path. Trying to think of the first element of "/" means you're treating the splitting inconsistently, which will make everything else harder.
So the problem really is that you're only getting three elements instead of four: the empty first element is getting dropped. You can fix that by quoting, like this:
local pwd="${PWD/#$HOME/~}"
pwd_list=( "${(s:/:)pwd}" )
(The extra space next to the outer parentheses isn't necessary, but it makes it a little easier to read.) You can even combine that into one expression:
pwd_list=( "${(s:/:)${PWD/#$HOME/~}}" )
I am trying to build my own shell in C as part of a class project. We are required to use execv and implement our own path. For better understanding here is the question:
The list of paths is empty by default, but may grow to any arbitrary size. You should implement a built-in command to control this variable:
path [+|- /some/dir]
path (without arguments) displays all the entries in the list separated by colons, e.g. "/bin:/usr/bin".
path + /some/dir appends the given pathname to the path list.
path - /some/dir removes the given pathname from the path list.
I have misread the assignment and used execvp so far. Please can you shed some light on how to create my own path variable, and for each command executed search the directory it is in and add it to the path? Or is there any simple shell written using execv I can take a look at?
I saw http://linuxgazette.net/111/ramankutty.html, but I found the search a little too complex, and he uses execve.
so far i have char *mypath variable which is null initially. but the user can add or remove using path + some/dir or path - /some/dir. syntax for execv is execv("/some/dir", argv) how do i search my path for the executable and pass it to execv....for example mypath=/bin/ls ; when i pass execv(mypath, argv) it does not work...so how do i pass the path to execv?
I'm guessing the reason you are supposed to use excev is precisely that it doesn't take into account the path of the environment, but the call has to provide a full path to the function.
Since this is a class project, you are supposed to write your code - writing code is how you learn how to do things, much more than copy-and-paste from the internet, so I'm not going to write code to solve the problem but instead describe the solution.
You will need to keep a list of path entries - adjusted through the path + some/dir and path - some/dir mechanism - so these commands need to be handled inside your shell, of course, and they should add/remove from your list of path entries.
When you then come to executing something, say "mycommand" is entered, you will have to scan the list of path entries, and check if there is a file by the name "mycommand" in the directory specified by the path entry that can be executed (has execute bit set in the directory entry). If so, call execv on the string of current path entry and "mycommand" concatenated. (You can produce the concatenated string and use the stat function to get the information about the file, for example)
Do check for errors, and report if something goes wrong.
Please do not try to find someone else's shell on the internet. That is not how you learn, and if you don't actually learn from the class exercises, you will most likely not succeed once you finish school - and that's ultimately WHY you are going to school, right?
I have a directory name and a subpath, e.g. "./files" and "/example.txt". While the directory can be arbitrarily placed in the filesystem, I need to make sure that directory+subpath ("./files/example.txt") actually is inside the given directory. So this example would be valid, while subpath "/../example.txt" would be invalid because it is neither a child of the directory, nor a grandchild, etc. Soft-links leading outside of the directory are allowed.
How should I perform this test in C?
My first guess was to use realpath(directory_subpath) and comparing the start of the result with realpath(directory), but after reading about the problems with PATH_MAX I'm a bit unsure about that, and this is also likely to cause problems with soft-links.
My second idea is simply checking if the subpath starts with /../ and if is, resulting in invalid. If /../ exists anywhere else in the subpath, the directory name before that will be removed (from left-to-right, repeating this until the path turns out to be invalid or the end of the path name is reached).
The subpath might be given with malicious intent, so I want to be really, really sure about this. Is my second approach safe? Is there a different, better way?
The second approach is safe if you check for /.. (without trailing slash).
I would just forbid .. in the subpath: the cases when .. is really necessary and is not malicious are rather rare.
I'm working on a C application that has to walk $PATH to find full pathnames for binaries, and the only allowed dependency is glibc (i.e. no calling external programs like which). In the normal case, this just entails splitting getenv("PATH") by colons and checking each directory one by one, but I want to be sure I cover all of the possible corner cases. What gotchas should I look out for? In particular, are relative paths, paths starting with ~ meant to be expanded to $HOME, or paths containing the : char allowed?
One thing that once surprised me is that the empty string in PATH means the current directory. Two adjacent colons or a colon at the end or beginning of PATH means the current directory is included. This is documented in man bash for instance.
It also is in the POSIX specification.
So
PATH=:/bin
PATH=/bin:
PATH=/bin::/usr/bin
All mean the current directory is in PATH
I'm not sure this is a problem with Linux in general, but make sure that your code works if PATH has some funky (like, UTF-8) encoding to deal with directories with fancy letters. I suspect this might depend on the filesystem encoding.
I remember working on a bug report of some russian guy who had fancy letters in his user name (and hence, his home directory name which appeared in PATH).
This is minor but I'll added it since it hasn't already been mentioned. $PATH can include both absolute and relative paths. If your crawling the paths list by chdir(2)ing into each directory, you need to keep track of the original working directory (getcwd(3)) and chdir(2) back to it at each iteration of the crawl.
The existing answers cover most of it, but it's worth covering parts of the question that wasn't answered yet:
$ and ~ are not special in the value of $PATH.
If $PATH is not set at all, execvp() will use a default value.
I am trying to get the parent directory of the current folder in which i have the program.
I need to include in the C program I have. I tried doing it through string methods and solve it, but I feel there can be a better and simpler way. Eg: If his path is “C:\Application\Config”, then I want to get - “C:\Application” the just parent path.
Can some one please help me with this?
Thanks,
Priyanka
To in-place truncate a string at its last backslash:
char pathname[MAX_PATH];
GetCurrentDirectory(MAX_PATH, pathname);
char* last_backslash = strrchr(pathname, '\\');
if (last_backslash)
{
*last_backslash = '\0';
}
Sometimes just adding \.. will suffice if you are not afraid by MAX_PATH.
It's difficult to answer your question since you haven't really specified what you want to -do- with the path once you have it. If you want to change to the new directory, that's easy, you just use whatever function you'd normally use to change directory but pass it ".." instead of a full path - that's because on all sane filesystems, ".." is a 'magic' directory which exists inside all other directories and refers to the parent thereof.
If you want to perform some string function on the new directory before jumping to it, your problem instantly becomes a lot more difficult to solve. The way I'd go about doing it mirrors RichieHindle's solution - strip the current directory away from the full path then you're left with the parent directory's path with which you can muck about to your heart's content.
In Windows OS, the API function you need is called GetCurrentDirectory().
http://msdn.microsoft.com/en-us/library/aa364934%28v=vs.85%29.aspx