zsh version 5.2
I'm attempting an array assignment using filename generation like so:
files=(/some/path/*/dir/myfile)
Indeed this is the way the zshoptions manual recommends to achieve what I want.
When no matches exist I want the array to be empty. Instead it's producing
no matches found: /some/path/*/dir/file
and the script terminates.
I've tried setting NULL_GLOB, CSH_NULL_GLOB and ensured NOMATCH is not set.
When matches do exist it works as expected.
Any help is appreciated.
Thank you in advance,
Wayne
Well of course I found the solution after posting my question.
For this to work EXTENDED_GLOB needs to be set as well as NULL_GLOB. Or a glob qualifier can be used so that NULL_GLOB only effects this particular expansion.
This is how to set NULL_GLOB for a single operation:
files=(/some/path/*/dir/myfile(N))
Hope that can help someone else who encounters this.
Wayne
Related
I have a question, I have been reviewing some code and in one script, the authors use:
if(0){
#do something
}
Any help in what if(0) means?
The author (most likely) put the block of code in an if statement so that they could easily remove it if necessary without having to comment it out (or remove it). Similar to if(true) or if(false), you just need to change one value and it would skip that code.
Upon reviewing the code, developers should remove these kinds of statements once they've finalized all their source code not to confuse others.
Looks like something that will never be executed, since 0 = FALSE. Most probably this is a manual switch to test some code in parenthesis.
The following is a simplified makefile for a problem I'm having:
all: /tmp/makey/../filey
#echo All done
/tmp/filey:
#echo Filey
When I run make it says:
make-3.79.1-p7: * No rule to make target /tmp/makey/../filey', needed byall'. Stop.
Clearly it does not realize that /tmp/makey/../filey is the same as /tmp/filey. Any ideas how I can make this work?
Thanks
Ciao
-- Murali
Newer versions of GNU make have $(abspath ...) and $(realpath ...) functions you can apply to your prerequisites and targets to resolve the paths to the same string. If you've constructed these names yourself (for example, $(PREFIX)/../filey) then you can use $(dir $(PREFIX))filey instead.
Other than that, there's no way to solve this problem. Make uses string matching on targets and if the strings are not identical, they don't match (there's a special case to ignore the simple prefix ./) Even if make understood this distinction (by applying abspath itself to each target name, maybe) it would still not help in the face of symbolic links for example.
The only "real" answer would be for make to understand something about the underlying file system (device IDs and inodes for example) that let you talk about files without referring to their pathname. However, in a portable program like make doing this is problematic.
I'd like to use alias to make some commands for myself when searching through directories for code files, but I'm a little nervous because they start with ".". Here's some examples:
$ alias .cpps="ls -a *.cpp"
$ alias .hs="ls -a *.h"
Should I be worried about encountering any difficulties? Has anyone else done this?
What is the advantage of putting the dot in the names? It seems like an unnecessary extra character. I'd just use the base names (hs and cpps) for the aliases.
I suppose that it might be argued that the dot indicates that the command is an alias - but why is that distinction beneficial? One of the great things about Unix was that it removed the distinction between hallowed commands provided by the O/S and programs written by the user. They are all equal - just located in different places.
I don't see any real dangers with using aliases that start with a dot. It would never have occurred to me to try; I'm mildly surprised that they are allowed. But given that they are allowed, there is no real risk involved that I can see.
I wouldn't use '.' to begin your aliases because it's next to '/' and you could hit the two together by mistake and accidentally run an executable in your current directory (especially if you use tab completion).
I doubt that there's any technical problem though it's likely to be confusing to anyone who has used Unix for a long time. In my world commands don't have dots in them and file names don't have spaces or upper case letters!
I have Vim 7.2 installed on Windows. In GVim, the <C-PageUp> and <C-PageDown> work for navigation between tabs by default. However, it doesn't work for Vim.
I have even added the below lines in _vimrc, but it still does not work.
map <C-PageUp> :tabp<CR>
map <C-PageDown> :tabn<CR>
But, map and works.
map <C-left> :tabp<CR>
map <C-right> :tabn<CR>
Does anybody have a clue why?
The problem you describe is generally caused by vim's terminal settings not knowing the correct character sequence for a given key (on a console, all keystrokes are turned into a sequence of characters). It can also be caused by your console not sending a distinct character sequence for the key you're trying to press.
If it's the former problem, doing something like this can work around it:
:map <CTRL-V><CTRL-PAGEUP> :tabp<CR>
Where <CTRL-V> and <CTRL-PAGEUP> are literally those keys, not "less than, C, T, R, ... etc.".
If it's the latter problem then you need to either adjust the settings of your terminal program or get a different terminal program. (I'm not sure which of these options actually exist on Windows.)
This may seem obvious to many, but konsole users should be aware that some versions bind ctrl-pageup / ctrl-pagedown as secondary bindings to it's own tabbed window feature, (which may not be obvious if you don't use that feature).
Simply clearing them from the 'Configure Shortcuts' menu got them working in vim correctly for me. I guess other terminals may have similar features enabeld by default.
I'm adding this answer, taking details from vi & Vim, to integrate those that are already been given/accepted with some more details that sound very important to me.
The alredy proposed answers
It is true what the other answer says:
map <C-PageUp> :echo "hello"<CR> won't work because Vim doesn't know what escape sequence corresponds to the keycode <C-PageUp>;
one solution is to type the escape sequence explicitly: map ^[[5^ :echo "hello"<CR>, where the escape sequence ^[[5^ (which is in general different from terminal to terminal) can be obtained by Ctrl+VCtrl+PageUp.
One additional important detail
On the other hand the best solution for me is the following
set <F13>=^[[5^
map <F13> :echo "hello"<CR>
which makes use of one of additional function key codes (you can use up to <F37>). Likewise, you could have a bunch of set keycode=escapesequence all together in a single place in your .vimrc (or in another dedicated file that you source from your .vimrc, why not?).
How can I tell unix "find" to include in it's recursive search a folder which is softlinked?
-L . This causes it to follow all symbolic (I assume this is what you mean by soft) links.
Interesting - I hadn't come across '-L' (or the opposite, '-H') before. You can also use '-follow' to do the same job. It can be built into expressions (it always evaluates to true), so you might be able to be more subtle with it that using '-L'. However, I wouldn't worry about that subtlety too much - the '-L' is simpler.
find some more information about unix find command at
http://scripterworld.blogspot.com/2009/07/unix-find-command-with-examples-and.html