I've got a script that I'm running where I declare the path I'm using, then define my source files as all the child items in that path.
$htmPath = "c:\users\x\desktop\cgc\ht"
$srcfiles = Get-ChildItem $htmPath -filter "*.htm*"
I've run this successfully in the past, but this morning I started getting the following error:
You must provide a value expression on the right-hand side of the '*' operator.
At C:\users\x\desktop\cgc\CGC002.PS1:63 char:46
+ $srcfiles = Get-ChildItem $htmPath -filter "* <<<< .htm*"
+ CategoryInfo : ParserError: (:) [], ParseException
+ FullyQualifiedErrorId : ExpectedValueExpression
To me, it appears that this error is being thrown because the script is interpreting my wildcard as a multiplication, and wants the value on the right side necessary to complete the operation. Am I interpreting it properly? If that is indeed the case, how do I make sure that my wildcard is interpreted as a widlcard?
I did find this link, but it's a different enough scenario with different enough code that I'm not sure it applies. However, I did find this comment in the thread interesting:
Try putting the *, at the start of the property list instead of the end. I think it's just getting confused. It's mainly your formatting.
...so I exited PS, warm-booted, the usual did-you-try-turning-it-off-and-back-on-again confusion resetters, and still, the same error.
Maybe I have a typo somewhere that I can't see?
Or, if I'm completely missing the interpretation of the error...school me.
Ended up being a single double-quote off the right side of my text editor. Color coded syntax checking helped me verify that it was a mismatched quote issue...thinking to scroll to the right to FIND the " took a lot more time than it should have. Facepalm.
Thanks to #Richard who offered up this suggestion.
Related
I'm using powerline, bash, and iterm2 on mac. I also installed gitstatus, but that didn't work when I installed it two days ago, and powerline worked just fine yesterday without gistatus functioning. Today, when I booted up the terminal, this error showed instead of the prompt.
Any advice? Where can I find the full log of the errors/interpret this message? Alternatively, how can I pinpoint which file has an error on line 55?
There error was in a color config file for the github integration. I was missing a comma at between lines. I believe it was in this file .config/powerline/colorschemes/default.json or another json related to it; see here.
Ultimately, I recommend moving to powerlevel10k. You can configure it to look exactly like powerline, but it a) updates cleanly (compared to powerline where if you update your python it breaks horribly) and b) comes with a really good customization setup and c) lets you use zsh + oh-my-zsh which gives so much additional functionality
I am attempting to send a file from IFS to an outq on our AS/400 system. Whenever I do, I get exactly what I send, as well as a line of "#" symbols of varying lengths appended to the end.
Here's the command I'm using:
qsh cmd('cat -c /path/test.txt | Rfile -wbQ -c "ovrprtf file(qprint)
outq(*LIBL/ABCD) devtype(*USERASCII) rplunprt(*no) splfname(test) hold(*no)"
qprint')
The contents of test.txt is just Hello World!
The output I get when I send the command is
Hello World!####################################################################
I have not found any posts online about a similar problem, and have tried changing values and looking for additional switches to get it to work. Nothing I'm doing seems to fix the issue.
Is there a command or switch that I am missing, or is something I have in there already causing this?
EDIT:
I found this documentation which is the first time I've seen this issue mentioned, but it's not very helpful:
“Messages for a Take Action command might consist of a long string of "at" symbols (#) in a pop-up message. (The Reflex automation Take Action command, which is configured in situations, does not have this problem.) A resolution for this problem is under construction. This problem might be resolved by the time of the product release. If you see this problem, contact IBM Software Support.”
The only differences are: 1) this is not a pop-up message, it's printed. 2) I don't believe we use Tivoli Monitoring, although I could be wrong.
Assuming we do use Tivoli Monitoring, what would the solution be? There's no additional documentation past that, and I am not a system administrator, so I can't really make the call to IBM Software Support myself. And assuming we DON'T use it, what else could cause this issue?
I get different results, yet similar. I created a test.txt with Windows Explorer, put in Hello, world!, saved it and tried the script. I got gibberish for the 'Hello, world!' and then the line of # symbols.
My system is 7.3 TR5, CCSID 37 (US English) and my IFS file is CCSID 1252 (Windows English). Results did not change if I used a stream file of CCSID 819 (US ASCII).
I didn't have any luck modifying Rfile switches.
I found that removing devtype(*userascii) produced printed output in plain English without the # symbols. Do you really need *USERASCII? I would think that would be more for a pre-formatted 'print-ready' file like Postscript or the like.
EDIT: some more things to try
I don't understand why *USERASCII is adding those # symbols; it looks like a translation issue.
I tried this and still got the extra ###... You might have to play with the TOCCSID() parameter. Although a failure, it did give me an idea: what if those # symbols are EBCDIC spaces being sent as-is to the *USERASCII print stream? All we'd need is a way to send only the number of bytes in the stream file, without any padding.
CRTPF FILE(QTEMP/PRTSTMF) RCDLEN(132)
CPY OBJ('/path/test.txt') TOOBJ('/qsys.lib/qtemp.lib/prtstmf.file/prtstmf.mbr') replace(*yes)
ovrprtf file(qprint) outq(*LIBL/prt3812) devtype(*USERASCII) rplunprt(*no) splfname(test) hold(*no)
cpyf prtstmf qprint
The data in QTEMP/PRTSTMF is in ASCII; DSPPFM shows that much. It also shows a bunch of spaces: after all, it is a fixed length file. My next step was to write an RPG program to read the stream file and print it, but Scott Klement already did that: http://www.scottklement.com/PrtStmf.zip
This works on my system:
ovrprtf file(qsysprt) outq(*LIBL/abcd) devtype(*USERASCII) rplunprt(*no) splfname(test) hold(*no)
prtstmf stmf('/path/test.txt') outq(abcd)
I have this simple DLV program consisting of few predicates and derivations rules. One of the rules is not being activated and I have no clue why since apparently all predicates exist. I have to admit I am no expert in DLV and a bit rusty since the last time I used it so please forgive me if this is too obvious :-/
Among others, I have this rule:
knows(ps, chunk(v, ps, pd)) :- value(v),
knows(ps, v),
connected(ps, pd).
And here you can see what I get after executing the code:
./dlv -nofinitecheck model.edb rules.idb
{participant(p1), participant(p2), participant(p3), value(v1),
value(r1), value(v2), value(r2), value(v3), value(r3),
connected(p1,p2), connected(p1,p3), connected(p2,p3), knows(p1,v1),
knows(p1,r1), knows(p2,v2), knows(p2,r2), knows(p3,v3), knows(p3,r3)}
Since I have "value(v1)" and "knows(p1,v1)" and "connected(p1,p2)", I was expecting the output of the program should contain "knows(p1, chunk(v1, p1, p2))".
Can anyone explain me why this is not happening?
Edit: I have removed all rules and created just this single one
chunk(v, ps) :- value(v), participant(ps).
But this rule is not being activated either! What's the problem? I have tried the simplest one:
chunk(v) :- value(v).
and no activation. What am I missing?
OK. I Just realised of my stupidity. The problem is I am using lowercase letters for the variables rather than capitol letters... Sorry, as I said I am rusty!
So, just for the record. Rather than chunk(v) :- value(v) it should be something like chunk(V) :- value(V)
I need help fixing a Python script, but know ABSOLUTELY NOTHING about Python (though I am an experienced programmer so I get the jargon.)
I have this script that is trying to write output to a generated path, but when I run it, it gives me an error saying something about "E:\Program", and when I check, sure enough, it creates a folder named "Program" in the root of my E: drive. I'm CERTAIN it is trying to write to "E:\Program Files" but the space is terminating the command.
I did find where "path" is assigned:
path = tkm.path_archuncomp + bs.path + bs.name + '.ext'
How would I enclose that path in quotes that are assigned to the variable?
Inserting the quotes character appears to be the same as languages like C. Simply use "slash" notion:
path = \" + some_variable + \"
Unfortunately for me, repairing the script is more complicated than that, and doing so only created errors, so I can't confirm that was done properly. :(
I am using XE8, win 8.1.
When trying load a file with spaces in directory, I am getting a exception of syntax name of the file or directory is invalid.
If I use imageen dialog to preview the file, no erros are found.
I did two tests with the procedure load_file1 and load_file2 and I have the same problem.
Is there a wrokaround to solve it?
function get_file:string;
begin
result:='"C:\Compartilhada\dicomserver versoes\dicomserverx\data\Genesis-1000\1.2.410.200013.1.215.1.200912141600580009_0001_000001_13061821270002.dcm"'
end;
procedure load_file1;
var fStm:Tstream;
p1:string;
begin
p1:=get_file;
fStm := tFileStream.Create( p1, fmOpenRead or fmShareDenyNone ); //->Error Here
try
TBlobField(FieldByName('dicom')).LoadFromStream(fStm);
Post;
finally
fSTm.Free;
end;
end;
procedure load_file2;
p1:string;
begin
p1:=get_file;
TBlobField(FieldByName('dicom')).LoadFromFile(p1); //-->Error Here
Post;
end;
Remove the double quote marks from your string. It should be:
'C:\Compartilhada\dicomserver versoes\dicomserverx\data\Genesis-1000\1.2.410.200013.1.215.1.200912141600580009_0001_000001_13061821270002.dcm'
You might use " for paths containing spaces in some situations, for instance a command interpreter. But at the API level, it is simply not needed. And indeed it is a mistake as you have discovered. The double quote character " is actually a reserved character in a file name. That is documented on MSDN:
Naming Files, Paths, and Namespaces: Naming Conventions
The following fundamental rules enable applications to create and process valid names for files and directories, regardless of the file system:
...
Use any character in the current code page for a name, including Unicode characters and characters in the extended character set (128–255), except for the following:
The following reserved characters:
< (less than)
> (greater than)
: (colon)
" (double quote)
/ (forward slash)
\ (backslash)
| (vertical bar or pipe)
? (question mark)
* (asterisk)
...
...
In comments below you indicate that the code in the question does not reflect your actual problem. Which makes me wonder how you expect us to help. Your real problem is not the error message produced by the specific code, but that your debugging skills are letting you down. Let me try to explain how to debug a problem like this.
First of all, you are passing a file name to LoadFromFile or TFileStream.Create. These calls fail with an error that indicates that the file name is not valid.
So, when faced with that knowledge, the first step is to check the value of the file name that you are passing. Use debugging techniques to do that. Either the IDE debugger, or logging.
Once you have identified what value you are actually passing to these functions you can try to work out what is invalid about it.
To repeat, your real problem is not with the specifics, but in your debugging skills. You should take this as an opportunity to learn more about debugging. Stack Overflow is not a substitute for debugging. Learn to debug better, and your life as a programmer will become very much easier.