10.0.55 - @FILEARRAY limitation

[Steve Fabian]

The command
echo %@filearray[zclip,clip:]
failed with the error message

TCC: (Sys) The filename, directory name, or volume label syntax is
incorrect.
"%@filearray[zclip,clip:]"

The failure of the operation is not a problem, since the alternate syntax
%@execarray[xclip,type clip:] works, but

1/ The error message quotes too much of the command - if the error can be
pinpointed to a command field containing the unacceptable filename, either
just the filename ought to be displayed, or (to provide better context) the
filename ought to be highlighted (suggestion for a future version?);

2/ A HELP comment in topic f_filearray.htm that only real files (but not
pseudofiles) are accepted would be useful.
--
Steve

 

[rconn]

Steve Fábián wrote:

> The command
> echo %@filearray[zclip,clip:]
> failed with the error message
>
> TCC: (Sys) The filename, directory name, or volume label syntax is
> incorrect.
> "%@filearray[zclip,clip:]"
>
> The failure of the operation is not a problem, since the alternate syntax
> %@execarray[xclip,type clip:] works, but
>
> 1/ The error message quotes too much of the command - if the error can be
> pinpointed to a command field containing the unacceptable filename, either
> just the filename ought to be displayed, or (to provide better context) the
> filename ought to be highlighted (suggestion for a future version?);

WAD - all variable functions behave this way, as in most cases it's too
difficult for the parser to pinpoint exactly what went wrong. (And in
some cases, it's impossible for the parser -- if it passes several
arguments to a Windows API and that API fails, there's usually no way to
know exactly which argument caused the problem.

Trying to make this smarter is on the list for a (distant) future
version -- the problem being that with more than 250 internal functions,
this is going to require (many) thousands of lines of new code. (And it
will certainly break some existing batch files and aliases).

> 2/ A HELP comment in topic f_filearray.htm that only real files (but not
> pseudofiles) are accepted would be useful.

None of the @FILE... functions accept CLIP:, which isn't surprising
since CLIP: is a pseudodevice, not a file or pseudofile.

Rex Conn
JP Software

 

[Steve Fabian]

rconn wrote:
| Steve Fábián wrote:
|| 2/ A HELP comment in topic f_filearray.htm that only real files (but
|| not pseudofiles) are accepted would be useful.
| ---End Quote---
| None of the @FILE... functions accept CLIP:, which isn't surprising
| since CLIP: is a pseudodevice, not a file or pseudofile.

Ah! That's the key - pseudodevice vs. pseudofile. This is hinted at in topic
"redirection.htm", where it refers to CLIP: as a pseudo-device [sic].

Incidentally, the last two paragraphs at the bottom of that topic use fonts
differently than normal.

It's interesting to note that the @line[] and @lines[] functions DO accept
CLIP:...
--
Steve

 

[rconn]

rconn wrote:
| Steve Fábián wrote:
|| 2/ A HELP comment in topic f_filearray.htm that only real files (but
|| not pseudofiles) are accepted would be useful.
| ---End Quote---
| None of the @FILE... functions accept CLIP:, which isn't surprising
| since CLIP: is a pseudodevice, not a file or pseudofile.

Ah! That's the key - pseudodevice vs. pseudofile. This is hinted at in topic
"redirection.htm", where it refers to CLIP: as a pseudo-device [sic].

Incidentally, the last two paragraphs at the bottom of that topic use fonts differently than normal.

It's interesting to note that the @line[] and @lines[] functions DO accept
CLIP:...
--
Steve

Since CLIP: doesn't exist in Windows, I have to add (a significant amount of) code to support it in each individual command or function. (And no, it's not possible to make that generic and share it everywhere, because it has to be done differently for each Windows API.)

So CLIP: only gets added where a significant number of users have requested it. (In the case of @LINE and @LINES, they share almost all their code so CLIP: only had to be added once.) Nobody had requested it for the @FILE... functions, and there doesn't seem to be a need for it there.

 

[Steve Fabian]

rconn wrote:

| Since CLIP: doesn't exist in Windows, I have to add
| (a significant amount of) code to support it in each
| individual command or function. (And no, it's not possible
| to make that generic and share it everywhere, because it
| has to be done differently for each Windows API.)

| So CLIP: only gets added where a significant number of users
| have requested it. (In the case of @LINE and @LINES, they
| share almost all their code so CLIP: only had to be added once.)
| Nobody had requested it for the @FILE... functions, and there
| doesn't seem to be a need for it there.

That's fine, the only one that could be useful (though I personally had not
had a need for it in the past) is @FILESIZE[]. A much simpler one would
would be @CLIPSIZE[] - or, since the function has no parameters anyway, an
internal variable _CLIPSIZE. Another clipboard attribute that could have
potential use is some scheme to be able to determine whether or not
clipboard content changed since some past epoch. One possible method is an
internal variable _CLIPAGE, which could be compared with a reference value -
if such is possible at all. Another scheme would need to save a hash of the
clipboard content, to be compared with the current hash, e.g. _CLIPHASH -
which could be e.g. a concatenation of clipboard size and its CRC32 hash.
The purpose of knowing whether or not the clipboard content changed is to
avoid duplicate processing. In my own clipboard operations at this time I
depend on my brain to perform this function. You could just add my ramblings
above to the suggestion list (without posting a response).

BTW, once again in responding you included my signature in the quoted text.
I had to quote your response by cut and paste (using what else? the
clipboard) and manually format the line lengths...
--
Steve