Нет ничего плохого в вашем подходе к раскрытию строки (интерполяция):
$new_folder_name = 'foo' # sample value
$des_path = "C:\path\to\newfolder\$new_folder_name" # use string expansion
возвращает строковый литерал C:\path\to\newfolder\foo
, как и ожидалось.
Ответ Адама показывает вам альтернативы построению путей к файлам, причем Join-Path
является наиболее надежным и PowerShell-идиоматическим, хотя и медленным.
Другой вариант - использовать [IO.Path]::Combine()
:
[IO.Path]::Combine('C:\path\to\newfolder', $new_folder_name)
Способ вычисления значения для $new_folder_name
должен быть проблематичным, если ваша текущая культура не en-US
(США-английский), но из-за ошибки на самом деле не«т [1] ;в любом случае это должно быть упрощено:
Вместо:
$x = $_.LastWriteTime.ToShortDateString()
$new_folder_name = Get-Date $x -uformat %V
используйте:
$new_folder_name = Get-Date $_.LastWriteTime -uformat %V
То есть, передайте $_.LastWriteTime
напрямую в Get-Date
, в качестве экземпляра [datetime]
- обхода через строковое представление не требуется.
[1] .ToShortDateString()
возвращает строковое представление, чувствительное к культуре , тогда как PowerShell обычно использует инвариантную культуру для обеспечения согласованности между культурами;поэтому, если вы передаете string параметру, который принимает экземпляр [datetime]
, то должны распознаваться только форматы культуры invariant , а не текущий культуры.Хотя это верно для функций , написанных на PowerShell , в скомпилированных командлетах (обычно на C #), культура current неожиданно применяется;хотя это ошибка , было принято решение не исправлять ее ради обратной совместимости - см. эту проблему GitHub