DEL unhides directories

[Steve Fabian]

I just tested V6 through the latest available build. The command

*del/eqyzxs x

unhides all hidden directories of the default directory, though it retains
lower level hidden directories. It correctly does its intended operation of
removing file x from anywhere in the tree and any directories made empty
thereby.

This side-effect of the /Z option is not documented, and it is highly
undesirable. We have the ATTRIB command to do the job when desired.

Note: I want to be able to delete file X from a hidden directory, without
unhiding the directory. This is an operation I frequently perform.
--
Steve

 

[rconn]

Steve Fábián wrote:

> I just tested V6 through the latest available build. The command
>
> *del/eqyzxs x
>
> unhides all hidden directories of the default directory, though it retains
> lower level hidden directories. It correctly does its intended operation of
> removing file x from anywhere in the tree and any directories made empty
> thereby.
>
> This side-effect of the /Z option is not documented, and it is highly
> undesirable. We have the ATTRIB command to do the job when desired.
>
> Note: I want to be able to delete file X from a hidden directory, without
> unhiding the directory. This is an operation I frequently perform.

WAD - has nothing to do with /Z; it has everything to do with /X.
Remove the /X switch from your command and it will work as desired.

(BTW, your command syntax is deplorable and will definitely break in
future versions!)

Rex Conn
JP Software

 

[Steve Fabian]

rconn wrote:
| Steve Fábián wrote:
|
|
| ---Quote---
|| I just tested V6 through the latest available build. The command
||
|| *del/eqyzxs x
||
|| unhides all hidden directories of the default directory, though it
|| retains lower level hidden directories. It correctly does its
|| intended operation of removing file x from anywhere in the tree and
|| any directories made empty thereby.
||
|| This side-effect of the /Z option is not documented, and it is highly
|| undesirable. We have the ATTRIB command to do the job when desired.
||
|| Note: I want to be able to delete file X from a hidden directory,
|| without unhiding the directory. This is an operation I frequently
|| perform.
| ---End Quote---
| WAD - has nothing to do with /Z; it has everything to do with /X.
| Remove the /X switch from your command and it will work as desired.

... but it would no longer perform all I wanted it to do, i.e., delete all
directories made empty by the self-same command.

When I dropped /z unhiding stopped. Anyway, it only unhides the top-level
hidden directories, not the lower level ones, as if I used "attrib/ad -h",
and it affects all directories, whether or not there is a matching file.

I still consider it undesirable, and it is definitely NOT documented.

| (BTW, your command syntax is deplorable and will definitely break in
| future versions!)

I know, and I use abbreviated syntax only at the command line. I am aware
that the only officially supported syntax is

*del /e /q /y /z /x /s x

which expands the command from 12 to 24 characters, doubling the typing.

Proper syntax is not an issue for aliases, minor issue for batch files.
--
Steve

 

[rconn]

Steve Fábián wrote:

> When I dropped /z unhiding stopped. Anyway, it only unhides the top-level
> hidden directories, not the lower level ones, as if I used "attrib/ad -h",
> and it affects all directories, whether or not there is a matching file.

/Z never changes any directory attributes. (It will remove "read-only"
file attributes.)

/X *must* change the directory attributes, as it's impossible to delete
hidden & system directories otherwise. It's also necessary to remove
the attribute before it continues to parse & delete subdirectories of
that directory.

> I still consider it undesirable, and it is definitely NOT documented.

It's behaved this way back to 4NT 2.0. It's probably never been
explicitly documented because it seemed obvious.

Rex Conn
JP Software

 

[David Marcus]

It's probably never been
explicitly documented because it seemed obvious.

Don't think I would have guessed it would do that.

 

[Steve Fabian]

rconn wrote:
| Steve Fábián wrote:
| ---Quote---
| ---End Quote---
| /X *must* change the directory attributes, as it's impossible to
| delete hidden & system directories otherwise. It's also necessary to
| remove
| the attribute before it continues to parse & delete subdirectories of
| that directory.

IIRC EXCEPT restores the state of the H attribute after completion for
objects that still exist, which it must do by saving the information. Can't
DEL do the same?

BTW, in my most common operation, where I observed and analyzed the issue,
no files are deleted from the originally hidden directories, and they do not
have subdirectories. I understand your statement above to mean that neither
hidden directories nor their subdirectories can be deleted, so they must be
unhidden. I am not quite certain what you mean by "parsing a subdirectory",
though I think you mean "search it for files to be deleted". Did you mean to
say that you cannot search a hidden directory for files or subdirectories
(and must therefore unhide it to search it)?
|
|
| ---Quote---
|| I still consider it undesirable, and it is definitely NOT documented.
| ---End Quote---
| It's behaved this way back to 4NT 2.0. It's probably never been
| explicitly documented because it seemed obvious.

I have long struggled with hidden directories becoming visible, possibly
even in 4DOS, but did not explicitly trace the problem to the specific
command. Yes, I had trouble ever since I started using hidden directories,
just did not explicitly determine the cause.

No, some internal limitations imposed by the OS are not obvious. The better
the product in accessing hidden (and system) objects the more you expect
from it. Retention of attributes not explicitly changed by a command is
certainly the expectation.
--
Steve

 

[rconn]

Steve Fábián wrote:

> rconn wrote:
> | Steve Fábián wrote:
> | ---Quote---
> | ---End Quote---
> | /X *must* change the directory attributes, as it's impossible to
> | delete hidden & system directories otherwise. It's also necessary to
> | remove
> | the attribute before it continues to parse & delete subdirectories of
> | that directory.
>
> IIRC EXCEPT restores the state of the H attribute after completion for
> objects that still exist, which it must do by saving the information. Can't
> DEL do the same?

EXCEPT does not do that.

> BTW, in my most common operation, where I observed and analyzed the issue,
> no files are deleted from the originally hidden directories, and they do
> not
> have subdirectories. I understand your statement above to mean that neither
> hidden directories nor their subdirectories can be deleted, so they must be
> unhidden.

That's correct.

> I am not quite certain what you mean by "parsing a subdirectory",
> though I think you mean "search it for files to be deleted". Did you
> mean to
> say that you cannot search a hidden directory for files or subdirectories
> (and must therefore unhide it to search it)?

No, I have to unhide it if you've specified an /X so DEL can delete it
when it returns from recursing into all the subdirectories. (DEL
doesn't have any way to know in advance that you didn't really mean to
delete that directory, even though you asked it to!)

Rex Conn
JP Software

 

[Steve Fabian]

rconn wrote:
| Steve Fábián wrote:
| ---Quote---
|| I am not quite certain what you mean by "parsing a subdirectory",
|| though I think you mean "search it for files to be deleted". Did you
|| mean to
|| say that you cannot search a hidden directory for files or
|| subdirectories (and must therefore unhide it to search it)?
| ---End Quote---
| No, I have to unhide it if you've specified an /X so DEL can delete it
| when it returns from recursing into all the subdirectories. (DEL
| doesn't have any way to know in advance that you didn't really mean to
| delete that directory, even though you asked it to!)

But I didn't ask to delete the top-level directory. I asked to delete it if
and only if it was not empty at the beginning, but at the end of operations
in its subdirectories it ends up empty. So the unhiding could be postponed
until it is necessary to actually delete the directory.

As TCC (and before it 4NT/TCMD and 4DOS) operate, any hierarchical clean-up
requires either a priori knowledge of hidden directories, or collecting that
information, so the directory attributes could be restored. I suspect, but
do not know, that some other commands (sync, copy, move, etc.) might also be
making similar changes to directory attributes.

It would be highly desirable to be able to process a directory tree without
changing any attributes of what remains.
--
Steve

 

[rconn]

Steve Fábián wrote:

> rconn wrote:
> | Steve Fábián wrote:
> | ---Quote---
> || I am not quite certain what you mean by "parsing a subdirectory",
> || though I think you mean "search it for files to be deleted". Did you
> || mean to
> || say that you cannot search a hidden directory for files or
> || subdirectories (and must therefore unhide it to search it)?
> | ---End Quote---
> | No, I have to unhide it if you've specified an /X so DEL can delete it
> | when it returns from recursing into all the subdirectories. (DEL
> | doesn't have any way to know in advance that you didn't really mean to
> | delete that directory, even though you asked it to!)
>
> But I didn't ask to delete the top-level directory. I asked to delete it if
> and only if it was not empty at the beginning, but at the end of operations
> in its subdirectories it ends up empty. So the unhiding could be postponed
> until it is necessary to actually delete the directory.

This would require a rewrite of the parser to change it to doing a
double (or sometimes triple) pass on the commands. Since this is about
20,000 lines of highly twitchy code, it's going to take a lot more than
one complaint in fifteen years to warrant several months of work! :-)

You can always write your own bottom-up DEL plugin ...

Rex Conn
JP Software

 

[Steve Fabian]

rconn wrote:
| This would require a rewrite of the parser to change it to doing a
| double (or sometimes triple) pass on the commands. Since this is
| about 20,000 lines of highly twitchy code, it's going to take a lot
| more than
| one complaint in fifteen years to warrant several months of work! :-)

This is not the first complaint, it has been brought up in the past, but I
can see the problem. The next best thing is to document that some commands
that can traverse a directory tree may change directory attributes. That
would eliminate complaints, or at least make it possible to quickly answer
them with WAD: RTFM.

However, maybe in V11 you could do that for all directory traversal, so that
e.g. COPY /F would never complete with newly created empty target
directories, no matter what.

| You can always write your own bottom-up DEL plugin ...

Only after I manage to write one to provide commands to handle arbitrary
strings without SETDOS /X.
--
Steve