i was wondering if it is possible to output backticks whithin a doxygen' code section.
~~~~~~~~~~
for file in `ls dir/*.filter`
do
done
~~~~~~~~~~
I get no output at all. And this seems to be caused by the backtick "`" i've inserted into my code section.
Does anyone had the same issue. Any suggestion?
many thanks
` is used to create an inline code block. Instead, use \code, \endcode rather than a markdown code block.
for example
\code
this is an inline `code block with ` characters
\endcode
renders with the ` characters included.
When a pair of `s is encountered in the code, doxygen will not process whatever is between.
The following will render correctly:
\code
for file in `ls dir/*.filter`
do
done
\endcode
Related
I use the amazing command line tool FZF
It offers the means to set its interface colours inline (Linux users get a config file, windows inline only):
Fzf --color=fg+:#00b4eb,bg+:#3d3c3c,hl:#0069fc,hl+:#0069fc --color=info:#80807e,prompt:#0069fc,pointer:#008ffc --color=marker:#008ffc,spinner:#454445,header:#353636
As you can see its a long line. besides I would like to build different configurations for different contexts via variables/functions , much like splatting parameters.
So I tried:
$Style = "--color=fg+:#00b4eb,bg+:#3d3c3c,hl:#0069fc,hl+:#0069fc --color=info:#80807e,prompt:#0069fc,pointer:#008ffc --color=marker:#008ffc,spinner:#454445,header:#353636"
FZF $Style
I get this error:
invalid color specification: hl+:#0069fc --color=info:#80807e
NativeCommandExitException: Program "FZFCommandLine.exe" ended with non-zero exit code: 2.
Even when I use a non expandable here string I get the same error:
$Conf = #'
--color=fg+:#00b4eb,bg+:#3d3c3c,hl:#0069fc,hl+:#0069fc --color=info:#80807e,prompt:#0069fc,pointer:#008ffc --color=marker:#008ffc,spinner:#454445,header:#353636
'#
I am trying to replicate the typical literal behaviour:
FZF --color=fg+:#00b4eb,bg+:#3d3c3c,hl:#0069fc,hl+:#0069fc --color=info:#80807e,prompt:#0069fc,pointer:#008ffc --color=marker:#008ffc,spinner:#454445,header:#353636
The part after Fzf is the part giving me trouble.
I'm trying to use sqlplus to do an Oracle query for the first time in a PowerShell script. I get this error message:
At line:1 char:73
+ ... user/pw#RRRPRD.company.net:1521/RRRPRDC #"C:\Users\ ...
+ ~
No characters are allowed after a here-string header but before the end of the line.
It seems to be pointing to the C: after #". Any ideas? I seem to be doing what is at this example. I get the same error when I try to do echoargs of the connection info.
This is my powershell code I am testing at the command line since it hangs forever running the program:
sqlplus user/pw#RRRPRD.company.net:1521/RRRPRDC #"C:\Users\me\Documents\2021\temp endToEnd\short.sql"
This is using powershell 5.1. Any ideas? I see here string header, but since I am following the example that was accepted in the link for sqlplus above, it's unclear to me what's wrong with it.
Replace
#"C:\Users\me\Documents\2021\temp endToEnd\short.sql"
with any of the following:
`#"C:\Users\me\Documents\2021\temp endToEnd\short.sql"
"#C:\Users\me\Documents\2021\temp endToEnd\short.sql"
'#C:\Users\me\Documents\2021\temp endToEnd\short.sql'
Note: Using a verbatim (single-quoted) string ('...') is arguably the best choice here, given that the path contains no variable references; if it did, a expandable (double-quoted) string ("...") would be equired.
All variations end up passing the following string verbatim to sqlplus, which I presume is your intent:
#C:\Users\me\Documents\2021\temp endToEnd\short.sql
Presumably, you're trying to pass # as a verbatim part of an argument to sqlplus - a common convention among CLIs is to use #<file-path> to request that argument data be taken from a file rather than using the argument value itself.
However, unlike in other shells, # is a metacharacter in PowerShell that serves a variety of purposes.
Thus, a # that should be a verbatim character at the start of an argument must either be escaped (with `) or part of a quoted string, as shown above. See the conceptual about_Special_Characters help topic.
If an unescaped argument-initial # is followed by " or ', PowerShell thinks you're trying to create a here-string, which has special, multi-line syntax requirements; the error message indicates that they're not met.
Question about running a custom function in Powershell.
I'm on Windows 10 and I'd like to somehow print my monorepository's directory tree structure excluding node_modules. This is not supported out of the box but requires a custom function to be defined. I found one solution on StackOverflow (https://stackoverflow.com/a/43810460/9654273), which would enable using a command like:
tree -Exclude node_modules -Ascii > tree.txt
The problem is I don't know what to do with the provided source code :D The answer says "add to your $PROFILE, for instance", so I ran notepad $PROFILE in PowerShell, pasted the code snippet there, saved it and tried running the command. It didn't work because I did something wrong. According to the StackOverflow post's comments from anand_v.singh and mklement0 I was still running some other tree command, not the one I just attempted to define.
So how do I use a custom function in PowerShell? Starting point is that source code is on StackOverflow and I don't know where to paste it. Or do you know some other, easier way to print a directory tree on Windows 10 excluding node_modules?
I had the same problem with that function. The issue is the special characters in the hashtable at line 106:
$chars = #{
interior = ('├', '+')[$ndx]
last = ('└', '\')[$ndx] #'
hline = ('─', '-')[$ndx]
vline = ('│', '|')[$ndx]
space = ' '
}
I changed the special characters to ascii as follows:
$chars = #{
interior = ('+', '+')[$ndx]
last = ('\', '\')[$ndx] #'
hline = ('-', '-')[$ndx]
vline = ('|', '|')[$ndx]
space = ' '
}
The only downside is that you do not now have the option of using special graphics characters (the Ascii switch is still there, but does nothing). Maybe someone could tell us how to embed them properly.
I know I can dot source a file:
. .\MyFunctions.ps1
But, I would like to dot source the commands in a string variable:
. $myFuctions
I see that this is possible:
.{$x=2}
And $x equals 2 after the script block is sourced.
But... .{$myFunctions} does not work.
I tried $myFunctions | Invoke-Expression, but it doesn't keep the source function in the current scope. The closest I have been able to come up with is to write the variable to a temporary file, dot source the file, and then remove the file.
Inevitably, someone will ask: "What are you trying to do?" So here is my use case:
I want to obfuscate some functions I intend to call from another script. I don't want to obfuscate the master script, just my additional functions. I have a user base that will need to adjust the master script to their network, directory structure and other local factors, but I don't want certain functions modified. I would also like to protect the source code. So, an alternate question would be: What are some good ways to protect PowerShell script code?
I started with the idea that PowerShell will execute a Base64-encoded string, but only when passed on the command line with -EncodedCommand.
I first wanted to dot source an encoded command, but I couldn't figure that out. I then decided that it would be "obfuscated" enough for my purposes if I converted by Base64 file into a decode string and dot sourced the value of the string variable. However, without writing the decoded source to a file, I cannot figure out how to dot source it.
It would satisfy my needs if I could Import-Module -EncodedCommand .\MyEncodedFile.dat
Actually, there is a way to achieve that and you were almost there.
First, as you already stated, the source or dot operator works either by providing a path (as string) or a script block. See also: . (source or dot operator).
So, when trying to dot-source a string variable, PowerShell thinks it is a path. But, thanks to the possibility of dot-sourcing script blocks, you could do the following:
# Make sure everything is properly escaped.
$MyFunctions = "function Test-DotSourcing { Write-Host `"Worked`" }"
. { Invoke-Expression $MyFunctions }
Test-DotSourcing
And you successfully dot-sourced your functions from a string variable!
Explanation:
With Invoke-Expression the string is evaluated and run in the child scope (script block).
Then with . the evaluated expressions are added to the current scope.
See also:
Invoke-Expression
About scopes
While #dwettstein's answer is a viable approach using Invoke-Expression to handle the fact that the function is stored as a string, there are other approaches that seem to achieve the same result below.
One thing I'm not crystal clear on is the scoping itself, Invoke-Expression doesn't create a new scope so there isn't exactly a need to dot source at that point...
#Define your function as a string
PS> $MyUselessFunction = "function Test-WriteSomething { 'It works!' }"
#Invoke-Expression would let you use the function
PS> Invoke-Expression $MyUselessFunction
PS> Test-WriteSomething
It works!
#Dot sourcing works fine if you use a script block
PS> $ScriptBlock = [ScriptBlock]::Create($MyUselessFunction)
PS> . $ScriptBlock
PS> Test-WriteSomething
It works!
#Or just create the function as a script block initially
PS> $MyUselessFunction = {function Test-WriteSomething { 'It works!' }}
PS> . $MyUselessFunction
PS> Test-WriteSomething
It works!
In other words, there are probably a myriad of ways to get something similar to what you want - some of them documented, and some of them divined from the existing documentation. If your functions are defined as strings, then Invoke-Expression might be needed, or you can convert them into script blocks and dot source them.
At this time it is not possible to dot source a string variable.
I stand corrected! . { Invoke-Expression $MyFunctions } definitely works!
I'm finding that in PowerShell 3, ExpandString is truncating my template string and only giving the very beginning of it. This worked in PowerShell 2 without a hitch, so I'm not sure what's going wrong.
The goal is to insert the value of $theSetting into the template string. Note that I use a regex to escape quotes and graves so that PowerShell doesn't try to expand them, and that appears to be working fine.
PS > $theSetting = 'x'
PS > $template = '<?xml version="1.0" encoding="utf-8" ?><AppSettings><Setting value="${theSetting}"/></AppSettings>'
PS > $template = $template -replace "('|`"|``)", '`$1'
PS > $template
<?xml version=`"1.0`" encoding=`"utf-8`" ?><AppSettings><Setting value=`"${theSetting}`"/></AppSettings>
PS > $ExecutionContext.InvokeCommand.ExpandString($template)
<?xml version="
For some reason, it's cutting it off after the first double quote. I appreciate any help in identifying what changed between PowerShell 2 and 3.
As you might guess given the template text, I'm actually loading the template from a file and writing the contents back out, and this is being used for configuration files that are far more variable and complex than the sample template seen here. So something simple like a regex instead isn't really an option.
For the benefit of future readers, don't do this. Use a real templating engine (e.g., Mustache).
Powershell 3 changed the way it parses strings to where you no longer need to change the " to `". I'm not quite sure why it evaluates it as the end of a string though.
Like Keith said, if you remove the replace code you have you will be fine. You can also detect to see if you are running on a lower powershell version and do the replacement like this:
if ($PSVersionTable.PSVersion.Major -lt 3) { $var = $var -replace '"','`"' }
Hope this helps