I have a Powershell script and no matter what I try it completely ignores any quotation marks in the script. The error occurs when I run the script from my VB.NET code yet, I have been running scripts successfully through VB.NET for a while now.
For example, my script starts with finding out the server name...
This works:
$name = gc env:computername
This does not:
$name = "SERVERNAME"
The error given is something along the lines of $name = SERVERNAME is not recognized as a cmdlet.... and so on.
This is causing several lines in my script to fail and the error message always displays the command WITHOUT the quotation marks.
When assigning string values you have to quote them (single or double quotes).
$name = 'SERVERNAME'
or
$name = "SERVERNAME"
or assign it directly to a variable (doesn't require quotes):
$name = $env:COMPUTERNAME
I'm not familiar with doing it from vbs, but the symptoms indicate the parser is discarding the quotes. If you double-qoute the strings:
$name = ""SERVERNAME""
It should discard the outer set, and leave you with the inner set.
Dim name As String = "SERVERNAME" maybe?
Related
I'm having an issue figuring out how to ignore signs and variables in a single quote string statement.
I am attempting to update a table with the new text with structure such as:
update xxx
set xxx =
'Our Ref. $BOOKING_NO$
.......
Kind regards'
If your $ chars are being interpreted, it isn't by Oracle ($ isn't special in Oracle anyway, and between single-quotes everything is a string), but rather by your client program or maybe shell script. If, for example, you are running this in SQL*Plus from a Unix-based shell script, you will need to use the appropriate means required by the shell you use to prevent the shell from interpreting $ and ' characters.
I would like to define a string variable in GAMS to call a server. Here is the syntax:
$set SERVER SERVER=ASERVER
The problem is that there is a space in the server name, so that the actual syntax is
$set SERVER SERVER=A SERVER
Then errors are reported like this "Error Unknow option "Server"". How should I handle a string variable with space in variable name? Thanks
Try it with quotes:
$set SERVER 'SERVER=A SERVER'
Edit: Another example how to use $call with an argument containing spaces (note that this is for Windows only, on Unix you would have to handle the spaces and quotes differently):
$echo $log %x% > log.gms
$call 'gams log.gms --x="With Space" lo=%gams.lo%'
Here's the problem: if I use { } for the update command like so:
package require sqlite3
fileRepo eval {UPDATE uploads SET $col=$data WHERE rowid=$id}
I cannot substitute any variables inside the curly brackets. it all has to be hard coded.
However, if I use " " for the update command like so:
fileRepo eval "UPDATE uploads SET $col='$data' WHERE rowid=$id"
I can substitute variables inside the double quotes, but I must use ' ' in order to put in data with spaces so sql sees it as one input. If I don't I get an error if I send something like
$data = "Legit Stack"
Because it has a space the sql will choke on the word: Stack
unless it is placed within single quotes
Therefore...
If I send this data to the update command:
$col = description
$data = "Stack's Pet"
I get the following error:
near "s": syntax error while executing "fileRepo eval "UPDATE uploads
SET $col='$data' WHERE rowid=$id" ...
Thus given these rules I can see no way to pass a single quote or apostrophe to the update command successfully. Is there a different way to do this?
Thanks!
While it is true that you can escape the single quotes by doubling them (as usual in SQL), you open up your code to the dangers of SQL injection attacks.
It might be better to split your code into two distinct steps:
Substitute with format {UPDATE uploads SET %s=$data WHERE rowid=$id} $col
let sqlite3 magic eval turn the $data and $id into bound variables for a prepared statement
This way you only need to sanitize your col variable, to make sure it contains a valid column name and nothing else (should be easy), instead of all your data. In addition, you do not need to copy large values as often, so a two step approach will even be faster. To make it even clearer you want to use a bind variable, try the alternative syntax with a : in front of a variable name.
package require sqlite3
set stmt [format {UPDATE uploads SET %s=:data WHERE rowid=:id} $col]
fileRepo eval $stmt
Recommended Reading:
For the : syntax: https://www.sqlite.org/tclsqlite.html#eval
For more information about SQL Injections: https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
You have to use an escape apostrophe. So it should look like this:
$data = "Stack''s Pet"
I am running a VBA program from SAS. The SAS code for this basically looks like:
%let worksheet =&i; *worksheet number;
%let xlsfile = %STR(""C:\Data\Excel Workbook.xlsx"");
%let csvfile = %STR(""C:\Data\CSV File..csv"");
x 'cd "C:\Data\MN2013\Alignment\Data\SAS Programs"';
x "XlsWsToCsv.vbs &xlsfile &worksheet &csvfile";
I need to be able to include two double quotes (i.e. "") at the beginning and end of the file paths in the xlsfile and csvfile for the VBA program to recognize the spaces in the file paths and run correctly.
MY PROBLEM:
I run this in SAS Enterprise Guide using SAS 9.3. In my log, directly after the variable definition is read in, the double quotes are underlined in red (usually indicating an error) with the number 49 below. There is no error message, but instead, in green I get the following note:
NOTE 49-169: The meaning of an identifier after a quoted string might change in a future SAS
release. Inserting white space between a quoted string and the succeeding
identifier is recommended.
To me, this says SAS is reading these double quotes. They are somehow only partially being masked. My VBA program runs, so I could continue with this; but I like clean error logs. Does anyone have any recommendations for how to completely mask my xlsfile and csvfile variables? I've tried using %STR (as shown in my example above), %BQUOTE, %SUPERQ, and a few other things to make this work.
Those pesky error messages! You were very close, but try this syntax instead:
%let xlsfile = %STR("")C:\Data\Excel Workbook.xlsx%STR("");
%let csvfile = %STR("")C:\Data\CSV File..csv%STR("");
Double double quotes inside double quotes resolve to a single double quote character, ie...
x """c:\program files\office\excel.exe"" stuff stuff stuff ""stuff"" stuff";
should work just fine. Don't worry about the 'identifier' message, that's largely saying something like
"01JAN2013"d
could be possible with other things. You can add a space after the last " if it's a problem to have that in the log.
When I use the following code, I only seem to print the last results from my array. I think it has something to do with my like clause and the % sign. Any ideas?
my #keywords = <IN>;
my #number = <IN2>;
foreach my $keywords (#keywords)
{
chomp $keywords;
my $query = "select *
from table1 a, table2 b
where a.offer = b.offer
and a.number not in (#number)
and a.title like ('%$keywords%')";
print $query."\n";
my $sth = $dbh->prepare($query)
or die ("Error: Could not prepare sql statement on $server : $sth\n" .
"Error: $DBI::errstr\n");
$sth->execute
or die ("Error: Could not execute sql statement on $server : $sth\n" .
"Error: $DBI::errstr\n");
while (my #results = $sth->fetchrow_array())
{
print OUT "$results[0]\t$results[1]\t$results[2]\t$results[3]\t",
"$results[4]\t$results[5]\t$results[6]\t$results[7]\t",
"$results[8]\n";
}
}
close (OUT);
I'm guessing that your IN file was created on a Windows system, so has CRLF sequences (roughly \r\n) between the lines, but that you're running this script on a *nix system (or in Cygwin or whatnot). So this line:
chomp $keywords;
will remove the trailing \n, but not the \r before it. So you have a stray carriage-return inside your LIKE expression, and no rows match it.
If my guess is right, then you would fix it by changing the above line to this:
$keywords =~ s/\r?\n?\z//;
to remove any carriage-return and/or newline from the end of the line.
(You should also make the changes that innaM suggests above, using bind variables instead of interpolating your values directly into the query. But that change is orthogonal to this one.)
Show the output of the print $query and maybe we can help you. Better yet, show the output of:
use Data::Dumper;
$Data::Dumper::Useqq=1;
print Dumper($query);
Until then, your comment about "replaces the an of and" makes me think your input has carriage returns, and the use of #number is unlikely to work if there's more than one.