Vista - Getting Copy-Item to display messages (like the old COPY command in CMD.EXE) ??

I REALLY appreciate you sticking with me on this Jacques but I still having
problems trying to get the behavior I want:

Compatibility with NT's DIR command

with the much more simple clause that you have shown

($_.Attributes -band 33) -eq 33

Rather than trying to explain this in words I'd like to show you

@"
"hello world" > x
CMD /C Attrib +a +r x
Copy x y
Copy x z
CMD /C Attrib +h z
CMD /C DIR /aar *
Get-ChildItem . | Where { (`$_.Attributes -band 33) -eq 33 }
"@ > test.ps1

Run this script

..\test

DIR . /aar will show the files x,y,z

where as

Get-ChildItem . | Where { (`$_.Attributes -band 33) -eq 33 }

will only show x and y.

If I'm mis-understanding the pipeline expression I'd appreciate you showing
it to me again because the above is not compatible

This clause

Where { (`$_.Attributes -band 33) -eq 33 }

was along the lines that I first took but the problem is the second logical
clause is comparing for equality not "at least"

thx
bob

"Jacques Barathon [MS]" wrote:

"Bob Landau" <BobLandau@xxxxxx> wrote in message
news:33B679C4-9543-4F79-A2EE-792A811C075B@xxxxxx....This is because by default get-childitem will not enumerate hidden files or
folders. Since you have activated the Hidden attribute on z, get-childitem
will only show x and y. Add -force to get-childitem and you will get what
you want.
Right, but let's take this from the beginning:

$_.Attributes -band 33

=> this will apply a binary AND between the attributes of a file and 33
which corresponds to Read only and Archive. The binary AND will result in
bits in common being flagged (set to 1). Bits that are either in the left
term or in the right term but not in both will be set to 0. The net result
is that if a file's attributes *include* Read only and Archive, it will have
those bits in common with the reference value of 33 and therefore the result
of the operation will be 33.

If a file has only one of those two attributes, or none of them, the binary
AND will only flag those bits in common and will likely result in a lesser
value than 33 (down to zero if no attribute is in common).

It doesn't matter if a file has other attributes than those two: the binary
operation won't catch the corresponding bits and those will remain set to 0
in the result.

Now, we move on to the "equality":

($_.Attributes -band 33) -eq 33

=> what we want to verify here is that only the files where the binary AND
flagged the Read only and Archive attributes are being captured. Since we
saw above that the expected result of the binary AND is 33, and that no
other value will describe what we want, that is exactly the equality we are
verifying here.

Hope I am making sense. Let me know if that's not clear enough.

Regards,
Jacques

"Bob Landau" <BobLandau@xxxxxx> wrote in message
news:8AB72523-4133-4912-AAC5-CA4D2A109F41@xxxxxxFYI we have some enhanced dir functions (dirx, dirs, dirt, dirw) in the
PowerShell community extensions, where you can do this:

dirx -force -recurse -setattr Readonly,Archive | Sort @{e={$_.CreationTime};
Des=$true}, @{e={$_.Name}; Asc=$true}

Execute dirx -? to get a list of all attributes you can use with -setAttr

--
Keith
http://www.codeplex.com/powershellcx

Thanks Keith,

I have started to look at the Community Extensions last week ( I wanted to
get a good handle on Powershell first). Frankly if I had look at this site
sooner I likely would not have written my script in the first place. On the
flip side I wouldn't have learned as much about PS as I know now.

DirX is more or less the same thing which I've submitted to the Community
Extensions. The main difference being that the syntax follows exactly the
DIR command; whether thats a positive or negative depends on your perspective.
The other difference is it can be used within a pipeline

thx
bob

"Keith Hill [MVP]" wrote:

Thank you for being patient with me. I had to look back on my previous code
version to see what provoked me to go the path I did. Some logic flaw which I
didn't see caused me to switch to my direction.

I've now changed this to model what you've been telling me which is much
simpler to read.

thx
bob

"Jacques Barathon [MS]" wrote:

"Bob Landau" <BobLandau@xxxxxx> wrote in message
news:2643FA11-7A90-4D22-A14F-F7E928C8E55B@xxxxxxNo worries. That's what community is here for.

Jacques