I've defined a conditional tag in my makefile so I can use the ONLY directive to conditionally remove blocks of text.
Makefile entry:
...
set BUILDDIR=_build
sphinx-build -t internal
...
I have a single LINE of information that I need to make disappear for a specific docs build. Here is the instance:
general:
workspace: "xxx"
<first indented list items>
.. only:: internal
xt-team-name: "phoenix" # for use with XT Grok - exclude this line otherwise **
<following list items - must stay put>
The 'internal' directive works, BUT it wipes out everything following the single line of text, that I DID NOT want to wipe out for this build. I have no spacebar characters or tab stops after the excluded text line - just a bare newline. I thought the newline would end the conditional operation?
What's the trick to get it to work on just the one piece? Can't move anything - it would disrupt the logic of the preceding and following indented sections of information. Tweaked the example to make it clearer.
White space has meaning in reStructuredText.
Indent the content that you want to hide for internal under the only directive.
Do not indent the content that you want to show.
general:
workspace: "xxx"
...
.. only:: internal
xt-team-name: "phoenix" # for use with XT Grok - exclude this line otherwise **
<following body of information>
Edit
Upon realizing that you want a list of items, not paragraphs, you can still get this to work with proper indentation.
List of Items
* One
* Two
.. only:: internal
* Two and one-half (hidden)
* Three
sphinx-build -b html . _build
sphinx-build -b html -t internal . _build
Also if you do not want "Two and one-half (hidden)" to be a member of a nested list, but of its parent list, then you can dedent it and its only directive.
Related
I am working with stock RHEL7/8 tools, and writing a script that will add a piece to a config file that is formatted as XML. I have run into a case where my sed statement can insert the added text inside a comment.
My current sed command gets the last existence of the tag <Program> and inserts the new tag after its closing tag </Program>.
How can I account for this possibly, but not always being inside a comment?
My script:
sed -i '0,/<Program id/s// <Program id=\"myProgram\"> <\/Program>' filepath
XML Example (displays the error inserting inside comment):
<Program id="myProgram"></Program>
<!--
<Program id="commentedOutProgram"></Program>
<Program id="newlyAddedProgram"><Program>
-->
EDIT:
This is happening at install time. I would like to add a way for some RHEL 7/8 built in tool to look in the XML file, make sure it's not in a comment, and add the new contents
Have a go with this. The usual caveats apply: It probably only works for exactly the sample you provided. Use a proper XML tool if you need a robust solution.
sed -e '/<!--/,/-->/b' \
-e '0,\%<Program id="[^"]*"></Program>%s%<Program id="myProgram"> </Program>%' filepath
Your original script seemed to have several errors, so I couldn't copy it verbatim, but this should at least give you an idea of how to modify it: add a b to skip any lines between <!-- and -->.
The % separators are just to avoid having to backslash slashes; sed allows you to use any separator you like instead of a slash, you just have to backslash the first one.
The b command jumps to a label; if the label is not specified, it jumps to the end of the script, i.e. skips the substitution part and starts over with the next line. The address expression before b selects any comment region, i.e. any lines between a line matching <!-- and a line matching -->.
I've browsed similar questions and believe i've applied all that i've been able to glean from answers.
I have a .yml file where as far as I can tell each element is formatted identically. And yet according to YamlLint.com
(<unknown>): mapping values are not allowed in this context at line 119 column 16
In this case, line 119 is the line containing the second instance the word "transitions" below. That I can tell each element is formatted identically. Am I missing something here?
landingPage:
include: false
transitions:
-
condition:location
nextState:location
location:
include:false
transitions:
-
condition:excluded
nextState:excluded
excluded:
include:false
transitions:
-
condition:excluded
nextState: excluded
-
condition:age
nextState:age
You cannot have a multiline plain scalar, such as your include:false transitions be the key to a mapping, that is why you get the mapping values not allowed in this context error.
Either you forgot that you have to have a space after the value indicator (:), and you meant to do:
include: false
transitions:
or you need to quote your multi-line scalar:
'include:false
transitions':
or you need to put that plain scalar on one line:
include:false transitions:
please note that some libraries do not allow value indicators in a plain scalar at all, even if they are not followed by space
I fixed this for myself by simply realizing I had indented a line too far, and un-indenting it.
we need to use space before ":"
Then it will excecute
check the yaml script in below
http://www.yamllint.com/
There are couple of issues in the yaml file, with yaml files it gets messy, fortunately it can be identified easily with tools like yaml lint
Install it
npm install -g yaml-lint
Here is how you can validate
E:\githubRepos\prometheus-sql-exporter-usage\etc>yamllint prometheus.yaml
√ YAML Lint successful.
For me the problem was a unicode '-' from a cut and paste. Visualy it looked OK, but the character was 'EN DASH' (U+2013) instead of 'HYPHEN MINUS' (U+002D)
In mine case it was the space after the : in a value:
query-url: https://blabla.com/blabla?label=blabla: blabla
To fix:
query-url: https://blabla.com/blabla?label=blabla:%20blabla
Or:
query-url: "https://blabla.com/blabla?label=blabla: blabla"
If you are using powershell and have copied the cat command, it won't work properly (I'm guessing it is encoding the content in some way). Instead of using "$(cat file.yaml)" you should use $(Get-Content file.yaml -Raw) without the quotes.
Really annoying!
In my case if was some odd disappearing of the initial formatting of the initial chart that was copied in Intellij Idea. It was possible to gfigure out with text-compare tool only:
So, when you do your copy and paste in your IDE, please double check is what you have copied is exactly what you paste, aren't some additional spaces were added.
What mistake am I making in the steps I'm following?
I've edited files in repo Alpha on my local box. I then realized I wanted those changes in a different repo Bravo that is also on my local box. I tried this:
c:/repos/alpha/>git diff --cached > mypatch.txt
I then copy the patch file to the other repo location and type this:
c:/repos/bravo/>git apply mypatch.txt
If the shell I used for the diff and apply was powershell or "Git CMD", then the second command makes the error:
fatal: unrecognized input
If instead I use the "Git Bash" shell to execute the two commands, then I get a different error:
5109e.patch:19: trailing whitespace.
IL.DataUsageGB,
warning: 1 line adds whitespace errors.
I then try to apply the changes more carefully with the following command:
$ git apply --reject --whitespace=fix mypatch.txt
From this I get a dump of numerous errors. Example:
error: while searching for:
);
GO
-- Anchor table ------------------------------------------------------------
-------------------------------------------
-- IL_InvoiceLine table (with 33 attributes)
----------------------------------------------------------------------------
-------------------------------------------
IF Object_ID('dbo.IL_InvoiceLine', 'U') IS NULL
CREATE TABLE [dbo].[IL_InvoiceLine] (
error: patch failed: scripts/bi/sql/Unified_ODS_Schema.sql:302
The branch in repo Alpha and the corresponding branch in repo Bravo both come from the same origin and both have a git status that report "up to date" with the upstream. In other words, the branches are identical except for the staged changes that exist on Alpha. I am expressly avoiding a push/pull with the origin.
Suggestions?
TL;DR
There's nothing wrong, and you can completely ignore the warning. You don't need --reject or --whitespace=fix, but if you do want to use the latter, use it without the former.
Longer
If the shell I used for the diff and apply was powershell ...
This winds up writing the output as Unicode (through some mechanism I cannot describe properly since I don't "do" Windows). You'd have to filter that back to UTF-8 or ASCII to get it to apply.
If instead I use the "Git Bash" shell to execute the two commands, then I get a different error:
5109e.patch:19: trailing whitespace.
IL.DataUsageGB,
warning: 1 line adds whitespace errors.
That's not really an error, that's a warning. It means that your original patch adds a blank before an end-of-line. By default, git apply calls this an "error" but it really means "warning". It's meant to alert you to the fact that there's an invisible character on the line(s) in question, which you may not have intended. (Or maybe you did! For instance, in some Markdown formats, ending a line with two blanks inserts a paragraph break. See aslo Git ignore trailing whitespace in markdown files only.)
What constitutes a "whitespace error" (which really should be "whitespace annoyance" or "whitespace warning" or "whitespace glitch" everywhere, rather than "error") is configurable. By default git diff will highlight such whitespace glitches. While I cannot quite show it here, imagine the - line is in red and the + line is in green and that <space> represents a trailing blank:
- blah blah
+ blah foo blah<space>
This space would be highlighted in red, to make it stand out as a "whitespace error" (which I would call a whitespace glitch or annoyance or warning, but as long as we are using Git we should understand what the phrase "whitespace error" means here).
With --whitespace=fix, git apply will find the things it considers to be whitespace errors and determine whether it can fix them automatically by:
stripping trailing whitespace
removing some space-before-tab spaces
fussing with CRLF vs LF-only
If it can fix them, it will. This includes applying the patch even if the context does not quite match up but can be made to do so by this kind of fussing, so it's more than just "removing trailing whitespace in the added lines".
I'm using jamplus to build a vendor's cross-platform project. On osx, the C tool's command line (fed via clang to ld) is too long.
Response files are the classic answer to command lines that are too long: jamplus states in the manual that one can generate them on the fly.
The example in the manual looks like this:
actions response C++
{
$(C++) ##(-filelist #($(2)))
}
Almost there! If I specifically blow out the C.Link command, like this:
actions response C.Link
{
"$(C.LINK)" $(LINKFLAGS) -o $(<[1]:C) -Wl,-filelist,#($(2:TC)) $(NEEDLIBS:TC) $(LINKLIBS:TC))
}
in my jamfile, I get the command line I need that passes through to the linker, but the response file isn't newline terminated, so link fails (osx ld requires newline-separated entries).
Is there a way to expand a jamplus list joined with newlines? I've tried using the join expansion $(LIST:TCJ=\n) without luck. $(LIST:TCJ=#(\n)) doesn't work either. If I can do this, the generated file would hopefully be correct.
If not, what jamplus code can I use to override the link command for clang, and generate the contents on the fly from a list? I'm looking for the least invasive way of handling this - ideally, modifying/overriding the tool directly, instead of adding new indirect targets wherever a link is required - since it's our vendor's codebase, as little edit as possible is desired.
The syntax you are looking for is:
newLine = "
" ;
actions response C.Link
{
"$(C.LINK)" $(LINKFLAGS) -o $(<[1]:C) -Wl,-filelist,#($(2:TCJ=$(newLine))) $(NEEDLIBS:TC) $(LINKLIBS:TC))
}
To be clear (I'm not sure how StackOverflow will format the above), the newLine variable should be defined by typing:
newLine = "" ;
And then placing the carat between the two quotes and hitting enter. You can use this same technique for certain other characters, i.e.
tab = " " ;
Again, start with newLine = "" and then place carat between the quotes and hit tab. In the above it is actually 4 spaces which is wrong, but hopefully you get the idea. Another useful one to have is:
dollar = "$" ;
The last one is useful as $ is used to specify variables typically, so having a dollar variable is useful when you actually want to specify a dollar literal. For what it is worth, the Jambase I am using (the one that ships with the JamPlus I am using), has this:
SPACE = " " ;
TAB = " " ;
NEWLINE = "
" ;
Around line 28...
I gave up on trying to use escaped newlines and other language-specific characters within string joins. Maybe there's an awesome way to do that, that was too thorny to discover.
Use a multi-step shell command with multiple temp files.
For jamplus (and maybe other jam variants), the section of the actions response {} between the curly braces becomes an inline shell script. And the response file syntax #(<value>) returns a filename that can be assigned within the shell script, with the contents set to <value>.
Thus, code like:
actions response C.Link
{
_RESP1=#($(2:TCJ=#)#$(NEEDLIBS:TCJ=#)#$(LINKLIBS:TCJ=#))
_RESP2=#()
perl -pe "s/[#]/\n/g" < $_RESP1 > $_RESP2
"$(C.LINK)" $(LINKFLAGS) -o $(<[1]:C) -Wl,-filelist,$_RESP2
}
creates a pair of temp files, assigned to shell variable names _RESP1 and _RESP2. File at path _RESP1 is assigned the contents of the expanded sequence joined with a # character. Search and replace is done with a perl one liner into _RESP2. And link proceeds as planned, and jamplus cleans up the intermediate files.
I wasn't able to do this with characters like :;\n, but # worked as long as it had no adjacent whitespace. Not completely satisfied, but moving on.
I have a directory "FS2" that contains the following files:
ARGH
this
that
I have a makefile with the following contents.
Template:sh= ls ./FS2/*
#all: $(Template)
echo "Template is: $(Template)"
touch all
When I run "clearmake -C sun" and the file "all" does not exist, I get the following output:
"Template is: ./FS2/#ARGH# ./FS2/that ./FS2/this"
Modifying either "this" or "that" does not cause "all" to be regenerated. When run with "-d" for debug, the "all" target is only dependent on the directory "./FS2", not the three files in the directory. I determined that when it expands "Template", the "#" gets treated as the beginning of a comment and the rest of the line is ignored!
The problem is caused by an editor that when killed leaves around files that begin with "#". If one of those files exists, then no modifications to files in the directory causes "all" to be regenerated.
Although, I do not want to make compilation dependent on whether a temporary file has been modified or not and will remove the file from the "Template" variable, I am still curious as to how to get this to work if I did want to treat the "#ARGH#" as a filename that the rule "all" is dependent on. Is this even possible?
I have a directory "FS2" that contains the following files: #ARGH# ...
Therein lies your problem. In my opinion, it is unwise using "funny" characters in filenames. Now I know that those characters are allowed but that doesn't make them a good idea (ASCII control characters like backspace are also allowed with similar annoying results).
I don't even like spaces in filenames, preferring instead SomethingLikeThis to show independent words in a file name, but at least the tools for handling spaces in many UNIX tools is known reasonably well.
My advice would be to rename the file if it was one of yours and save yourself some angst. But, since they're temporary files left around by an editor crash, delete them before your rules start running in the makefile. You probably shouldn't be rebuilding based on an editor temporary file anyway.
Or use a more targeted template like: Template:sh= ls ./FS2/[A-Za-z0-9]* to bypass those files altogether (that's an example only, you should ensure it doesn't faslely exclude files that should be included).
'#' is a valid Makefile comment char, so the second line is ignored by the make program.
Can you filter out (with grep) the files that start with # and process them separately?
I'm not familiar with clearmake, but try replacing your template definition with
Template:sh= ls ./FS2/* | grep -v '#'
so that filenames containing # are not included in $(Template).
If clearmake follows the same rules as GNU make, then you can also re-write your target using something like Template := $(wildcard *.c) which will be a little more intelligent about files with oddball names.
If I really want the file #ARGH# to contribute to whether the target all should be rebuilt as well as be included in the artifacts produced by the rule, the Makefile should be modified so that the line
Template:sh= ls ./FS2/*
is changed to
Template=./FS2/*
Template_files:sh= ls $(Template)
This works because $(Template) will be replaced by the literal string ./FS2/* after all and in the expansion of $(Template_files).
Clearmake (and GNU make) then use ./FS2/* as a pathname containing a wildcard when evaluating the dependencies, which expands in to the filenames ./FS2/#ARGH# ./FS2/that ./FS2/this and $(Template_files) can be used in the rules where a list of filenames is needed.