I am given a task to transition PL/SQL code to T-SQL.
Can anybody explain what SET DEFINE ON does in sqlplus and most impooirtantly how to translate it to T-SQL (I suppose using sqlcmd as a launcher?)
SET DEFINE is an SQL*Plus command setting the use and prefix for substitution variables. & is the default prefix and SET DEFINE ON resets it to this default and turns on the use of substitution variables.
So this is not a PL/SQL thing but an SQL*Plus thing.
As far as I know there's no such thing as substitution variables for sqlcmd, i.e. there's no equivalent for sqlcmd let alone T-SQL. But I might be wrong there.
'&' appears to be a token of the metalanguage used by SQL*Plus (the client, that is) to activate its "variable substitution" feature. So string literals containing '&' ("Marks & Spencer") tokens may not behave entirely as expected. SET DEFINE apparently serves to control that activation.
Related
What I would like to archieve is to be able to use :< shell command and add the output to the shell command to the cursor's position in neovim.
It seems I could use :redir to archieve this functionality and wrap it in to a function.
Is there a way to associate a [neo]vim function to :command?
A command can't return value. Hence a command is not an expression. And in particular, commands never can be "nested" one into another, like function calls. Cf. Shell scripting, for example.
In principle, there are some tricks, like a builtin function that accepts command name, runs it, and returns output as string value. But this is rather "convenient redir", not "syntax breaker".
To add external tool output into cursor position use, for example,
put=system('blah blah')
This is legal, as (some of) commands may accept expressions, including function calls.
Make sure to escape "bars" and "double quotes" though, as (sometimes) they are special in VimScript.
For ex, I have a query in postgreSQL such that "product_version=:productVersion".
It's giving me a syntax error.
It's giving you a syntax error because it makes no sense as SQL, and is invalid syntax.
(Please always show the exact text of error messages*)
Since inserting the string literal :productVersion doesn't make much sense, e.g.
product_version=':productVersion'
you might be using the psql command line client and trying to substitute a client variable. If so, you need to use a quoted substitution, e.g.:
product_version=:'productVersion'
but this only works for psql. Not Rails and the Pg gem, not JDBC, not PHP, not psycopg2, nothing but psql.
If that's not what you meant, then either you are using a programming language with placement parameters and using the wrong parameter syntax for your language, or you are attempting to use the psql command line client's variable substitution and aren't using psql. Impossible to guess what you mean unless you specify the language/tools used.
Look up the placement parameter syntax for your programming language and database driver. Make sure you're using the right one.
I wrote a Perl program that colorize its output.
Unfortunately I also have an interpreter that runs my program and display its output with no understanding of any ANSI escape sequences.
What is the correct way to simply bypass Term::ANSIColor? It would be awful to always treat both cases for each say or print statement i.e. say ($ENV{'TERM'} ne 'NONE')?colored('foo', green):'foo';
Any suggestion is welcome.
Use the ANSI_COLORS_DISABLED environment variable:
ANSI_COLORS_DISABLED
If this environment variable is set to a true value, all of the functions defined by this module (color(), colored(), and all of the constants not previously used in the program) will not output any escape sequences and instead will just return the empty string or pass through the original text as appropriate. This is intended to support easy use of scripts using this module on platforms that don't support ANSI escape sequences.
I am trying to translate a .bat file to PowerShell and having trouble with understanding what a few snippets of code is doing:
set MY_VARIABLE = "some\path\here"
"!MY_VARIABLE:\=/!"
What is line 2 above doing? Specially, I dont understand what the :\=/ is doing since I have seen the variable else where in the code being referenced like !MY_VARIABLE!.
The other point of confusion is the below code.
set SOME_VARIABLE=!SOME_ARGUMENTS:\=\\!
set SOME_VARIABLE=!SOME_ARGUMENTS:"=\"!
Also, can you tell me what is going on in lines 3 and 4 above as well?
What would the below variables translate into PowerShell as well?
set TN0=%~n0
set TDP0=%~dp0
set STAR=%*
Any help on this is much appreciated. Thanks.
The !var:find=replace! is string substitution for a variable that is delay-expanded.
http://www.robvanderwoude.com/ntset.php#StrSubst
When you use ! instead of % for a variable, you want DOS to do the variable replacement at execution time (which is probably what you think it does with %, but it doesn't). With %, the variable is substituted at the point that the command is parsed (before it's run) -- so if the variable changes as part of the command, it won't be seen. I think some switch to using ! all of the time, because it gives "normal" behavior.
You can read more about delayed expansion here
http://www.robvanderwoude.com/ntset.php#DelayedExpansion
The first two set variableName= commands use modifiers to expand on the name of the batch file, represented as %0.
%~n0 expands it to a file name, and
%~dp0 expands it to include a drive letter and path.
The final one, %*, represents all arguments passed to the batch file.
Additional information can be found in answers here or here.
Exclamation points (!) i n DOS batch files reference the intermediate value, useful if you are in a for-loop. If you were to use a % instead (in a loop), it would return the same value over and over.
Lines 3 and 4 are setting "SOME_VARIABLE" to the intermediate value of "SOME_ARGUMENTS:\=\" and SOME_ARGUMENTS:"=\", respectively. Again, I'm guessing that these lines are from a loop.
As for the variable assignments, Powershell variable assignments work like this:
$myVariable = "my string"
~dp0 (in DOS batch) translates into the path (with drive letter) of the current bat file. You can get that in Powershell by doing a "get-location".
Why someone would need to set a variable for STAR(*) is beyond me, so I'm assuming there was some encoding issue or other reason that they couldn't just use an asterisk.
~n0 I'm not sure about; maybe someone else knows what that one is.
I am optimizing a very time/memory consuming program by running it over a dataset and under multiple parameters. For each "run", I have a csv file, "setup.csv" set up with "runNumber","Command" for each run. I then import this into a perl script to read the command for the run number I would like, extrapolate the variables, then execute it on the system via the system command. Should I be worried about the potential for this to be exploited, (I am worried right now)? If so, what can I do to protect our server? My plan now is to change the file permissions of the "setup.csv" to read only and ownership to root, then go in as root whenever I need to append another run to the list.
Thank you very much for your time.
Run your code in taint mode with -T. That will force you to carefully launder your data. Only pass through strings that are ones you are expecting. Do not launder with .*, but rather check against a list of good strings.
Ideally, there a list of known acceptable values, and you validate against that.
Either way, you want to avoid the shell by using the multi-argument form of system or by using IPC::System::Simple's systemx.
If you can't avoid the shell, you must properly convert the text to pass to the command into shell literals.
Even then, you have to be careful of values that start with -. Lots of tools accept -- to denote the end options, allowing other values to be passed safely.
Finally, you might want to make sure the args don't contain the NUL character (\0).
systemx('tool', '--', #args)
Note: Passing arbitrary strings is not possible in Windows. Extra validation is required.