I'm trying to print a message with QMake but I have problems with extensions:
lib_name = $$1
message("test1: $$MYPATH/$$lib_name/src/$$lib_name.pri");
message("test2: $$MYPATH/$$lib_name/src/$$lib_name");
For some reason, test1 doesn't print the correct path. It just prints the path until src/. But, test2 is ok. It prints everything until the value in $$1.
Any workaround?
QMake supports variables (objects) with members that can be used using the dot . operator e.g. target.path for INSTALLS. So, in your case, $$lib_name.pri means that you're accessing the member pri of lib_name which doesn't exist so there's no output.
You need to enclose variables in curly braces for QMake to distinguish them from the surrounding text i.e. $${lib_name}.pri.
Example:
message("test1: $$MYPATH/$$lib_name/src/$${lib_name}.pri");
# ~~~~~~~~~~~~
For more examples of objects, see Adding Custom Target and Adding Compilers sections of QMake's Advanced Usage page.
Here's another relevant SO thread: QMake - How to add and use a variable into the .pro file
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
My ASP.NET website references refresh files that are being excluded because they reside in the ...\bin\ directory of projects.
What can I add to my .hgignore file to ensure just the ...\bin\*.refresh files are NOT excluded?
Note: I understand I could use hg add ...\bin\my.dll.refresh for each of the references and continue with my .hgignore, but I'd like to avoid needing to manually add specific files types as this is error prone and easy to forget.
# use glob syntax
syntax: glob
# Ignore Visual Studio 2008 files
src/**.obj
src/**.exe
src/**.pdb
src/**.user
src/**.aps
src/**.pch
src/**.vspscc
src/**_i.c
src/**_p.c
src/**.ncb
src/**.suo
src/**.tlb
src/**.tlh
src/**.bak
src/**.cache
src/**.ilk
src/**.log
src/**.lib
src/**.sbr
src/**.scc
src/***/[Bb]in <---- Problem child
src/***/[Dd]ebug*/
src/***/obj/*
src/***/[Rr]elease*/
src/*_ReSharper*/
src/*[Tt]est[Rr]esult*
src/*[Bb]uild[Ll]og.*
src/*.[Pp]ublish.xml
src/***/PrecompiledWeb/
For "all except some names" you must use:
regexp pattern
add negative lookahead in regexp "all files"(get "all except in this subset" as result)
syntax: regexp
bin/(?!.*\.refresh$).+
in any case, check and debug this expression, using filenames with pattern bin\*.*refresh* and hg status command
I would like to use regular expression in the form created using ploneformgen 1.7. I am using plone 4.1. In the custom validation of a text field.
How do I use the regular expression?
I tried the following:
python: import re; test(value==re.search(r'[123]'), False, 'Needs to be number 1 or 2 or 3')
but it gives me error and hence cannot validate.
I want value should be 1 or 2 or 3. I am able to use the expression as
python: test(value=='1' or value=='2' or value=='3', False, 'Needs to be number 1 or 2 or 3')
BUT I would like to use regular expressions. Please guide.
The set of packages and types that you may use in through-the-web scripts, TALES "python:" expressions, PFG overrides and PFG script adapters is limited to those available in Restricted Python. Restricted Python is deliberately very conservative in which modules and types it makes available.
You may expand the list with explicit "allow" declarations made in a Python package included in your egg list. A sample of such a package is available in the github collective, and includes several modules and types that I've found particularly useful in PloneFormGen, including re.
You will still not be able to "import re" in a TALES expression, but you will be able to use re in a TTW script, which may be used as a PFG validator.
Per http://docs.zope.org/zope2/zope2book/ScriptingZope.html, you cannot use regular expressions in TALES, since they are forbidden by Restricted Python.
You actually need 2 parameters for the search method.
You should use this way: import re; test(re.search(r'[123]', value), False, 'Needs to be number 1 or 2 or 3')
In particular, why is that sometimes the options to some commands are preceded by a + sign and sometimes by a - sign?
for example:
sort -f
sort -nr
sort +4n
sort +3nr
These days, the POSIX standard using getopt() (aka getopt(3)) is widely used as a standard notation, but in the early days, people were experimenting. On some machines, the sort command no longer supports the + notation. However, various commands (notably ar and tar) accept controls without any prefix character - and dd (alluded to by Alok in a comment) uses another convention altogether.
The GNU convention of using '--' for long options (supported by getopt_long(3)) was changed from using '+'. Of course, the X11 software uses a single dash before multi-character options. So, the whole thing is a collection of historic relics as people experimented with how best to handle it.
POSIX documents the Utility Conventions that it works to, except where historical precedent is stronger.
What styles of option handling are there?
[At one time, SO 367309 contained the following material as my answer. It was originally asked 2008-12-15 02:02 by FerranB, but was subsequently closed and deleted.]
How many different types of options do you recognize? I can think of
many, including:
Single-letter options preceded by single dash, groupable when there is
no argument, argument can be attached to option letter or in next
argument (many, many Unix commands; most POSIX commands).
Single-letter options preceded by single dash, grouping not allowed,
arguments must be attached (RCS).
Single-letter options preceded by single dash, grouping not allowed,
arguments must be separate (pre-POSIX SCCS, IIRC).
Multi-letter options preceded by single dash, arguments may be
attached or in next argument (X11 programs; also Java and many programs on Mac OS X with a NeXTSTEP heritage).
Multi-letter options preceded by single dash, may be abbreviated
(Atria Clearcase).
Multi-letter options preceded by single plus (obsolete).
Multi-letter options preceded by double dash; arguments may follow '='
or be separate (GNU utilities).
Options without prefix/suffix, some names have abbreviations or are
implied, arguments must be separate. (AmigaOS
Shell)
For options taking an optional argument, sometimes the argument must be attached (co -p1.3 rcsfile.c),
sometimes it must follow an '=' sign. POSIX doesn't support optional
arguments meaningfully (the POSIX getopt() only allows them for the last
option on the command line).
All sensible option systems use an option consisting of double-dash
('--') alone to mean "end of options" — the following arguments are
"non-option arguments" (usually file names; POSIX calls them 'operands')
even if they start with a
dash. (I regard supporting this notation as an imperative. Be aware that if the -- is preceded by an option requiring an argument, the -- will be treated as the argument to the option, not as the 'end of options' marker.)
Many but not all programs accept single dash as a file name to mean
standard input (usually) or standard output (occasionally). Sometimes,
as with GNU 'tar', both can be used in a single command line:
... | tar -cf - -F - | ...
The first solo dash means 'write to stdout'; the second means 'read file
names from stdin'.
Some programs use other conventions — that is, options not preceded by a
dash. Many of these are from the oldest days of Unix. For example,
'tar' and 'ar' both accept options without a dash, so:
tar cvzf /tmp/somefile.tgz some/directory
The dd command uses opt=value exclusively:
dd if=/some/file of=/another/file bs=16k count=200
Some programs allow you to interleave options and other arguments
completely; the C compiler, make and the GNU utilities run without
POSIXLY_CORRECT in the environment are examples. Many programs expect
the options to precede the other arguments.
Note that git and other VCS commands often use a hybrid system:
git commit -m 'This is why it was committed'
There is a sub-command as one of the arguments. Often, there will be optional 'global' options that can be specified between the command and the sub-command. There are examples of this in POSIX; the sccs command is in this category; you can argue that some of the other commands that run other commands are also in this category: nice and xargs spring to mind from POSIX; sudo is a non-POSIX example, as are svn and cvs.
I don't have strong preferences between the different systems. When
there are few enough options, then single letters with mnemonic value
are convenient. GNU supports this, but recommends backing it up with
multi-letter options preceded by a double-dash.
There are some things I do object to. One of the worst is the same
option letter being used with different meanings depending on what other
option letters have preceded it. In my book, that's a no-no, but I know
of software where it is done.
Another objectionable behaviour is inconsistency in style of handling
arguments (especially for a single program, but also within a suite of
programs). Either require attached arguments or require detached
arguments (or allow either), but do not have some options requiring an
attached argument and others requiring a detached argument. And be
consistent about whether '=' may be used to separate the option and
the argument.
As with many, many (software-related) things — consistency is more
important than the individual decisions. Using tools that automate
and standardize the argument processing helps with consistency.
Whatever you do, please, read the TAOUP's Command-Line Options and
consider Standards for Command Line Interfaces. (Added by J F
Sebastian — thanks; I agree.)
It's completely arbitrary; the command may implement all of the option handling in its own special way or it might call out to some other convenience functions. The getopt() family of functions is pretty popular, so most software written even remotely recently follows the conventions set by those routines. There are always exceptions, of course!
It's left to apps to parse options hence the inconsistency. Expanding on your sort example these are all equivalent for coreutils:
sort -k3
sort --k 3
sort --key 3
sort --key=3
_POSIX2_VERSION=199209 sort +2
A shell command is just a program, and it is free to interpret its command line any way it likes.
Unix never had anything like Apple's interface police to make sure that the command-line interface was consistent across applications. As a result, there is inconsistency, especially in older commands.
Peering into my crystal ball, I think command-line tools will slowly migrate toward GNU standards, double dashes and all. (I grew up with single dashes and still find the double dash very awkward, but it is consistent.)