Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

WAD PDIR @IF bug, @WORD bug

Jul
32
0
Hi,

20 years user of 4DOS / NDOS / 4NT etc.
(Using version TCC 14.00.29 x64 on Windows 7)

A small bug:
The following:​
pdir /(@if[1,%%@filesize[*],%%@filesize[*]] fn)​
prints:​
%@if[1,8994580,8994580] Windows​
instead of:​
8994580 Windows​

Another bug, not sure what the extent of it, appears when using @word. It only works on file names with no spaces in them. The following:
pdir /(@word["\",0,*] fpn)​
prints:​
"C:\Program Files" C:\Program Files​
C: C:\Windows​
instead of:​
C: C:\Program Files​
C: C:\Windows​
Cheers,
Gilad
 
A small bug:
The following:​
pdir /(@if[1,%%@filesize[*],%%@filesize[*]] fn)​
prints:​
%@if[1,8994580,8994580] Windows​
instead of:​
8994580 Windows​

Not a bug -- you've invented a new feature (and then reported that it doesn't work! :)).

The "@function[*]" syntax in PDIR only accepts a single argument, and you're passing it two. I might be able to support your specific instance (@IF[...]) in a future build.
 
Another bug, not sure what the extent of it, appears when using @word. It only works on file names with no spaces in them. The following:
pdir /(@word["\",0,*] fpn)​
prints:​
"C:\Program Files" C:\Program Files​
C: C:\Windows​
instead of:​
C: C:\Program Files​
C: C:\Windows​

WAD -- what this is being expanded to is this:

pdir /(@word["\",0,"C:\Program Files")

The filenames returned for the * argument are double quoted if they contain whitespace. This was requested (well, demanded) by users who didn't want to have to explicitly enter the quotes. So your @WORD function sees a single (double quoted) argument, and returns the whole thing.

You're probably trying to push PDIR a little too far -- these examples would be better handled with a DO loop.
 
Code:
pdir /(@if[1,%%@filesize[*],%%@filesize[*]] fn)

The first parameter of @IF should be a conditional expression as defined in HELP -> Conditional Expressions, not a number, which is a numeric expression. This is not C/C++! In the IF command the result of some of the @IS... functions is parsed in the manner of a C/C++, but not elsewhere.

Another bug, not sure what the extent of it, appears when using @word. It only works on file names with no spaces in them. The following:
pdir /(@word["\",0,*] fpn)​
prints:​
"C:\Program Files" C:\Program Files​
C: C:\Windows​
instead of:​
C: C:\Program Files​
C: C:\Windows​
WAD. As discussed at length many versions before the current one. the * symbol representing the full name of the current directory entry is quoted when it contains special characters, such as spaces, but not otherwise. When the last parameter of @WORD is a quoted string, the whole string is parsed as its word 0 regardless of the chosen word separator. If you want the drive letter followed colon :)), use
Code:
pdir/(@left[2,%%@path[*]] fpn)
 
The "@function[*]" syntax in PDIR only accepts a single argument, and you're passing it two.
Mmm - wasn't aware of that - probably worth a clarification in the help text...

No need to create a special build for me :). I did circumvent the issue with a Do loop, but still use the @output of a PDIR as it is quicker than doing @filesize for every file...

Still would be handy to have the full capabilities of @functions within a PDIR. In addition, I have some feature requests for it, but I'll open a new thread for that.
 
Just digested the bit about @WORD with double quotes :eek:. This makes it meaningless. Wouldn't make more sense to strip the double quotes and return the requested word?
 
Just digested the bit about @WORD with double quotes :eek:. This makes it meaningless. Wouldn't make more sense to strip the double quotes and return the requested word?
Not really meaningless. Most environment variables contain unquoted strings, functions and internal variables likewise, so @WORD will operate on them flawlessly. It is only in the * symbolic representation of the current directory entry in PDIR where the value is automatically quoted the issue can come up; one can use the @UNQUOTES function to remove the quotation marks, or use functions intended to analyze file specifications instead of generic string analyzers.
 
one can use the @UNQUOTES function to remove the quotation marks
Indeed adding @unquotes works as intended, but Rex pointed out that nested @fun[] syntax in PDIR is an invented feature so YMMV
Code:
E:\>pdir /(@word["\",0,%%@unquotes[*]] fpn) c:\
C: C:\PerfLogs
C: C:\Program Files
 

Similar threads

Back
Top