I have a problem switching combined conditions from TYPO3 9 LTS to TYPO3 10 LTS.
The syntax so far looks like this:
[PIDinRootline = 31] && [treeLevel = 4]
page.10.variables.cagmenu < lib.cagpagebrowser
[global]
I adapted the new syntax as follows:
[31 in tree.rootLineIds] && [tree.level == 5]
page.10.variables.cagmenu < lib.cagpagebrowser
[global]
If I omit the second condition && [tree.level ==4] the desired behaviour is implemented on all subpages of the page with ID=31.
How do I have to implement my condition accordingly so that it also works under TYPO3 10 LTS?
The logical operater has to be used inside the square brackets.
so your condition would be:
[31 in tree.rootLineIds && tree.level == 5] or
[31 in tree.rootLineIds and tree.level == 5]
More information can be found in the manual
Related
I want a job to run when 2 conditions are met:
There has been a merge request on the branch
A specific variable is not set
With the latest Gitlab in saas mode, I put this config in my job:
rules:
- if: ('$CI_PIPELINE_SOURCE == "merge_request_event"') && ($DESTROY_ONLY == null)
But it's run on a push. Do you see why?
The issue was an incorrect syntax. It should rather be:
rules:
- if: '($CI_PIPELINE_SOURCE == "merge_request_event") && ($DESTROY_ONLY == null)'
The following Perl 5 script:
use strict;
use warnings;
use Data::Printer;
my #a = (1,2,3,4);
p #a;
gives output:
(note the blue color), whereas this Perl 6 scripts:
use Data::Printer:from<Perl5>;
my #a = 1,2,3,4;
p #a;
gives output:
[
[0] 1,
[1] 2,
[2] 3,
[3] 4
]
but the numbers are not colored (as for the Perl 5 case above).
System information:
$ perl --version
This is perl 5, version 29, subversion 3 (v5.29.3) built for x86_64-linux
$ perl6 -e '.say for $*DISTRO, $*VM, $*PERL.compiler.version'
ubuntu (18.10.Cosmic.Cuttlefish)
moar (2018.11)
v2018.11
This seems to be an issue with version 0.40 of Data::Printer which is the current version on metacpan. If I install version 0.99 from GitHub I get colors with Perl 6 also. See also this issue.
I debugged version 0.40 a little bit, and it seems like the only difference between the call to p #a from Perl 5 version versus the same call from Perl 6, is that the Perl 6 call is called in list context, so wantarray returns true for the Perl 6 call, this apparantly makes Data::Printer turn off coloring somehow.
I believe this is valid Clojure code - and runs fine in a Lein console REPL - but errors inside the Cursive REPL:
Connecting to local nREPL server...
Clojure 1.8.0
nREPL server started on port 41303 on host 127.0.0.1 - nrepl://127.0.0.1:41303
*ns*
=> #object[clojure.lang.Namespace 0x4394b860 "user"]
(defn concat-some
[f vec1 vec2]
((fn [x] (filter f x)
(concat vec1 vec2))))
=> #'user/concat-some
(concat-some even? [1 2 3] [4 5 6])
clojure.lang.ArityException: Wrong number of args (0) passed to: user/concat-some/fn--4953
Am I missing something here?
Thank you for your help!
Edit and Follow-up:
This is definitely a Parinfer issue. This code:
(defn concat-some
[f vec1 vec2]
((fn [x] (filter f x))
(concat vec1 vec2)))
(concat-some even? [1 2 3] [4 5 6])
when pasted into the Cursive REPL with Parinfer turned on produces an incorrect paste and the resulting ArityException above. The same code pasted into the same REPL with Paredit turned on or Structural Editing turned off produces the expected output:
;; => #'user/concat-some
;; => (2 4 6)
I did not know that Structural Editing when active in Cursive is used in the editor - AND the REPL. I would still hope that valid code is valid code regardless of mode and wonder if this is the intended result of pasting into a Cursive/Parinfer REPL.(?)
Thank you again for your help with this.
Your editor might have a slurp/barf command that you accidentally triggered with a keyboard shortcut, but this copy/paste has gone awry.
You have (( which is generally a bad sign unless done correctly like in the examples:
(defn concat-some
[f vec1 vec2]
((fn [x] (filter f x))
(concat vec1 vec2)))
(concat-some even? [1 2 3] [4 5 6])
In yours the last paren on the line with filter is missing, and put at the end of the function instead. this means you are calling a function with 0 arguments, but your call to fn produces a function that takes 1 argument x
I have a tuple in my pig script:
((,v1,fb,fql))
I know I can choose elements from the left as $0 (blank), $1 ("v1"), etc. But can I choose elements from the right? The tuples will be different lengths, but I would always like to get the last element.
You can't. You can however write a python UDF to extract it:
# Make sure to include the appropriate ouputSchema
def getFromBack(TUPLE, pos):
# gets elements from the back of TUPLE
# You can also do TUPLE[-pos], but this way it starts at 0 which is closer
# to Pig
return TUPLE[::-1][pos]
# This works the same way as above, but may be faster
# return TUPLE[-(pos + 1)]
And used like:
register 'myudf.py' using jython as pythonUDFs ;
B = FOREACH A GENERATE pythonUDFs.getFromBack(T, 0) ;
How to clear the cache of $PATH in BASH. Every time I modify the $PATH, the former modifications are conserved too! So my $PATH is already one page :-), and it bothers me to work, because it points to some not right places (because every modification is being appended in the end of the $PATH variable). Please help me to solve this problem.
because every modification is being
appended in the end of the $PATH
variable
Take a close look at where you are setting $PATH, I bet it looks something like this:
PATH="$PATH:/some/new/dir:/another/newdir:"
Having $PATH in the new assignment gives you the appending behavior you don't want.
Instead do this:
PATH="/some/new/dir:/another/newdir:"
Update
If you want to strip $PATH of all duplicate entries but still maintain the original order then you can do this:
PATH=$(awk 'BEGIN{ORS=":";RS="[:\n]"}!a[$0]++' <<<"${PATH%:}")
PATH=$(echo $PATH | tr ':' '\n' | sort | uniq | tr '\n' ':')
Once in a while execute the above command. It will tidy up your PATH variable by removing any duplication.
-Cheers
PS: Warning: This will reorder the Paths in PATH variable. And can have undesired effects !!
When I'm setting my PATH, I usually use this script - which I last modified in 1999, it seems (but use daily on all my Unix-based computers). It allows me to add to my PATH (or LD_LIBRARY_PATH, or CDPATH, or any other path-like variable) and eliminate duplicates, and trim out now unwanted values.
Usage
export PATH=$(clnpath /important/bin:$PATH:/new/bin /old/bin:/debris/bin)
The first argument is the new path, built by any technique you like. The second argument is a list of names to remove from the path (if they appear - no error if they don't). For example, I have up to about five versions of the software I work on installed at any given time. To switch between versions, I use this script to adjust both PATH and LD_LIBRARY_PATH to pick up the correct values for the version I'm about to start using, and remove the values of the version I'm no longer using.
Code
: "#(#)$Id: clnpath.sh,v 1.6 1999/06/08 23:34:07 jleffler Exp $"
#
# Print minimal version of $PATH, possibly removing some items
case $# in
0) chop=""; path=${PATH:?};;
1) chop=""; path=$1;;
2) chop=$2; path=$1;;
*) echo "Usage: `basename $0 .sh` [$PATH [remove:list]]" >&2
exit 1;;
esac
# Beware of the quotes in the assignment to chop!
echo "$path" |
${AWK:-awk} -F: '#
BEGIN { # Sort out which path components to omit
chop="'"$chop"'";
if (chop != "") nr = split(chop, remove); else nr = 0;
for (i = 1; i <= nr; i++)
omit[remove[i]] = 1;
}
{
for (i = 1; i <= NF; i++)
{
x=$i;
if (x == "") x = ".";
if (omit[x] == 0 && path[x]++ == 0)
{
output = output pad x;
pad = ":";
}
}
print output;
}'
Commentary
The ':' is an ancient way of using /bin/sh (originally the Bourne shell - now as often Bash) to run the script. If I updated it, the first line would become a shebang. I'd also not use tabs in the code. And there are ways to get the 'chop' value set that do not involve as many quotes:
awk -F: '...script...' chop="$chop"
But it isn't broken, so I haven't fixed it.
When adding entries to PATH, you should check to see if they're already there. Here's what I use in my .bashrc:
pathadd() {
if [ -d "$1" ] && [[ ":$PATH:" != *":$1:"* ]]; then
PATH="$PATH:$1"
fi
}
pathadd /usr/local/bin
pathadd /usr/local/sbin
pathadd ~/bin
This only adds directories to PATH if they exist (i.e. no bogus entries) and aren't already there. Note: the pattern matching feature I use to see if the entry is already in PATH is only available in bash, not the original Bourne shell; if you want to use this with /bin/sh, that part'd need to be rewritten.
I have a nice set of scripts that add path variables to the beginning or end of PATH depending on the ordering I want. The problem is OSX starts with /usr/local/bin after /usr/bin, which is exactly NOT what I want (being a brew user and all). So what I do is put a new copy of /usr/local/bin in front of everything else and use the following to remove all duplicates (and leave ordering in place).
MYPATH=$(echo $MYPATH|perl -F: -lape'$_=join":",grep!$s{$_}++,#F')
I found this on perlmonks. Like most perl, it looks like line noise to me so I have no idea how it works, but work it does!