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

Folks,

I really enjoy PowerShell, and its power - but sometimes, things are a
bit irritating - like the fact that teh Copy-Item command doesn't seem
to display messages about what it's doing at all. You never get any
feedback printed on the standard out console to let you know that a
file has indeed been copied.....

Any way to turn that on?? I didn't find any mention of it in the "man
pages" as far as I can tell.....

Thanks!
Marc

use the -verbose switch

Brandon Shell
---------------
Blog: http://www.bsonposh.com/
PSH Scripts Project: www.codeplex.com/psobject

MS> Folks,
MS>
MS> I really enjoy PowerShell, and its power - but sometimes, things are
MS> a bit irritating - like the fact that teh Copy-Item command doesn't
MS> seem to display messages about what it's doing at all. You never get
MS> any feedback printed on the standard out console to let you know
MS> that a file has indeed been copied.....
MS>
MS> Any way to turn that on?? I didn't find any mention of it in the
MS> "man pages" as far as I can tell.....
MS>
MS> Thanks!
MS> Marc

This is currently my biggest complaint about Powershell; with the awkwardness
of using the Get-ChildItem cmdlet to query/sort for file properties being
2nd; and Powershell's gratuitously providing you with _any_ non-existant (of
your choice) Property which then will evaluate to NULL being the 3rd

I have not found an equivalent to what you want Copy-Item -verbose will
merely tell you that you've overwritten a "precious" file _after_ the fact.
-Confirm will ask you to validate the request regardless of whether there is
a file to overwrite.

Powershell has given us all the tools but for every day useage there needs
to be some additional functionalithy that provides us non-*nix's with the
safety and convience most of us are use to.

"Marc Scheuner" wrote:

While I agree... copy-item should have -noclobber switch.. it is easy to add
with test-path

Get-childitem | foreach{if(!(test-path $destination\$($_.Name)){copy-item $_
$destination\$_.Name -verbose}}

I dont understand the other things you dont like... I would like to know
more. Do you think you could clarify your frustration?

"Bob Landau" <BobLandau@xxxxxx> wrote in message
news:87E163FE-2B8E-4C6D-A4BE-7D0E382ACCFA@xxxxxx

Ok in regards to Get-ChildItem/Copy-Item or any of these other generalized
cmdlets I'm really not frustrated. I just find them awkward to use for
"typical" file system maintance.

Your example on how to prevent a file from being silently overwritten is an
example. Yes it is a "one-liner" but so is CMD's

copy *.txt \archive

and "copy" will warn you if it's about to clobber a file.

Here is another example using Get-ChildItem; say I'd like to find all files
that have their archive and read-only bit set and order these by Creation
time and then by name. For CMDs "dir" its done this way

dir c:\junk /aar-d /o-dn /tc

however to do the same thing for GCI you need a longer line even if you do
use the shortcut aliases

gci "c:\junk" | % { $attr = $( $_.get_Attributes() ); if ( -not ( ( $attr
-bxor 33 ) -band 33 ) -and -not ( $attr -band 16 ) ) { $_} } | Sort
@{e={$_.CreationTime}; Descending=$true}, @{e={$_.Name}; Ascending=$true}

33 is ReadOnly | Achive and 16 is directory I used the values rather than
the constants to shorten up the line.

In both of these cases most people would prefer to use simpler, older method.


Lastly the "gratuitous" synthetic property that PowerShell provides. This I
definitely _do_ find frustrating.

It applies mostly when you're writting a script and and mis-spell a property
rather than get a parse error you suffer a runtime error because your logic
likely was expecting a value back of some sort. Here is a simple example

(dir).count
(dir).noexistantproperty

The second line returns $null rather than "property not found" which is what
the next example will do

(dir).noexistantproperty()

error method not found

Set-PSDebug -strict won't even help here. Unfortunately I don't think I'll
ever be able to program without a typo here or there. This is very
frustrating.

thx
bob

"Brandon Shell [MVP]" wrote:

"Bob Landau" <BobLandau@xxxxxx> wrote in message
news:8AB72523-4133-4912-AAC5-CA4D2A109F41@xxxxxxOne of the truly beautiful aspects of PowerShell is that
Get-ChildItem/Copy-Item don't know anything about the Windows filesystem.
They work with any PowerShell provider to get and copy whatever widgets the
provider provides.

I expect to see Get-FileInfo, Copy-File and other filesystem specific
cmdlets in either a furture version of PowerShell or a future release of
PSCX.

"Bob Landau" <BobLandau@xxxxxx> wrote in message
news:8AB72523-4133-4912-AAC5-CA4D2A109F41@xxxxxx
....Not to disqualify your overall comment, but you should be aware of how you
can simplify the above command:

dir c:\junk | where {$_.attributes -eq 33} | sort
@{e={$_.creationtime};desc=$true}, name

Jacques

"Bob Landau" <BobLandau@xxxxxx> wrote in message
news:8AB72523-4133-4912-AAC5-CA4D2A109F41@xxxxxx
....Not to disqualify your general comment, but you should be aware of how you
can simplify the above command:

dir c:\junk | where {($_.attributes -band 33) -eq 33} | sort
@{e={$_.creationtime};desc=$true}, name

1) "where {<condition>}" provides the same logic as "foreach {if
(<condition>) {$_}}" and is much shorter.
2) You don't need to explicitly filter out directories since filtering on
Archive and Read only already rules them out.
3) As a result of 1 and 2, you only have to access the Attributes property
once therefore you don't need to use a temporary variable.
4) Sort order is ascending by default on all properties regardless of the
other properties' settings, so you don't need to be explicit on properties
that you want to sort this way.

Hope that helps,
Jacques

I wasn't aware directories would never have the archive bit set but they can
have read, hidden and system (c:\windows\assembly is one of many directories
other attributes set.

At least one reason that it's convoluted is to keep compatibility with how
"CMD /C DIR" processes attribues. This will not work.

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

because DIR only cares whether these attributes are set or not. For instance
if all I want is the Readonly/System files in the Windows directory it will
return any files that have these bits set. Any other attribute can also be
set and it will still be consider a match so equality can't be used.

There may be a simpler solution than mine. I agree it does seem more complex
than it needs to be but the only way I know of is to

1) $_.attributes XOR 33 (remove all the bits that I'm interested in)
2) AND the above result with 33 (the result will only be truie if the
"interesting" bits weren't set on $_)
3) lastly reverse the logic. The result will be true only as long as the
bits which I'm interested are set; any other bits are ignored.

I suppose I could have just used $_Attributes twice rather than the temp
$var which would have meant I could then use WHERE. But my code is written
now and I want to get this up on the scripting site as is.

thx
bob

"Jacques Barathon [MS]" wrote:

"Bob Landau" <BobLandau@xxxxxx> wrote in message
news:6CE1A1EC-2FF8-4CE9-A6A6-593EDF30EC0E@xxxxxxHave you tested it?
Yes it can. I am not testing Attributes as being equal to 33, I am testing
the value as having "at least" the bits that make 33 as a combination of
possible attributes. If a file has other attributes it will also be
recognised as positive to the match.

Does that make sense?

Jacques