В соответствии с документацией Cloudera вы должны начать его с --hostname
и --priviliged
Из документов
docker run --hostname=quickstart.cloudera --privileged=true -t -i [OPTIONS] [IMAGE] /usr/bin/docker-quickstart
Пояснения к требуемым флагам и другим опциям находятся в следующей таблице:
--hostname=quickstart.cloudera Required: pseudo-distributed configuration assumes this hostname
--privileged=true Required: for HBase, MySQL-backed Hive metastore, Hue, Oozie, Sentry, and Cloudera Manager, and possibly others
-t Required: once services are started, a Bash shell takes over and will die without this
-i Required: if you want to use the terminal, either immediately or attach later
-p 8888 Recommended: maps the Hue port in the guest to another port on the host
-p [PORT] Optional: map any other ports (e.g. 7180 for Cloudera Manager, 80 for a guided tutorial)
-d Optional: runs the container in the background
Что-то очень быстрое:
14:47:28 PS>pwd
C:\Documents and Settings\me\Desktop
14:47:30 PS>$path = pwd
14:48:03 PS>$path
C:\Documents and Settings\me\Desktop
14:48:16 PS>$files = Get-ChildItem $path -recurse |
Where {$_.Name -match "thisfiledoesnt.exist"}
14:50:55 PS>if ($files) {write-host "the file exists in this path somewhere"
} else {write-host "no it doesn't"}
no it doesn't
(создайте новый файл на рабочем столе или в папке на рабочем столе и назовите его thisfileexists.txt)
14:51:03 PS>$files = Get-ChildItem $path -recurse |
Where {$_.Name -match "thisfileexists.txt"}
14:52:07 PS>if($files) {write-host "the file exists in this path somewhere"
} else {write-host "no it doesn't"}
the file exists in this path somewhere
Конечно, итерация все еще происходит, но PS делает это за вас. Вам также может понадобиться -force при поиске системных / скрытых файлов.
Как насчет чего-нибудь более простого:
PS> gci . -r foo.txt
Здесь неявно используется параметр -filter (по позиции), определяющий foo.txt в качестве фильтра. Вы также можете указать * .txt или foo? .Txt. Проблема с StartsWith заключается в том, что при обработке сравнения без учета регистра все еще существует проблема, заключающаяся в том, что оба / и \ являются допустимыми разделителями путей в PowerShell.
Предполагая, что файл может не существовать, а пути $ file и $ directory являются абсолютными, вы можете сделать это способом "PowerShell":
(Split-Path $file -Parent) -replace '/','\' -eq (Get-Item $directory).FullName
Но это не очень хорошо, поскольку вам все равно нужно канонизировать путь / -> \ но по крайней мере сравнение строк PowerShell не чувствительно к регистру. Другой вариант - использовать IO.Path для канонизации пути, например:
[io.path]::GetDirectoryName($file) -eq [io.path]::GetFullPath($directory)
Одна из проблем заключается в том, что GetFullPath также сделает относительный путь абсолютным путем на основе процесса ' s текущий каталог, который чаще всего не совпадает с текущим каталогом PowerShell. Поэтому просто убедитесь, что $ directory является абсолютным путем, даже если вам нужно указать его как «$ pwd \ $ directory».
Что-то вроде этого?
Get-ChildItem -Recurse $directory | Where-Object { $_.PSIsContainer -and `
$_.FullName -match "^$($file.Parent)" } | Select-Object -First 1
Так как путь может не существовать, использование string.StartsWith
подходит для выполнения этого типа теста (хотя OrdinalIgnoreCase
является лучшим представлением того, как файловая система сравнивает пути ).
Единственное предостережение - пути должны быть в канонической форме. В противном случае такие пути, как C: \ x \ .. \ a \ b.txt
и C: /a/b.txt
, не сработают "это под C : \ a \
каталог "test. Вы можете использовать статический метод Path.GetFullPath
, чтобы получить полные имена путей перед выполнением теста:
function Test-SubPath( [string]$directory, [string]$subpath ) {
$dPath = [IO.Path]::GetFullPath( $directory )
$sPath = [IO.Path]::GetFullPath( $subpath )
return $sPath.StartsWith( $dPath, [StringComparison]::OrdinalIgnoreCase )
}
Также обратите внимание, что это не распространяется на логическое включение (например, если у вас есть \ \ some \ network \ path \
сопоставлен с Z: \ path \
, проверяется, находится ли \\ some \ network \ path \ b.txt
под Z: \
завершится ошибкой, даже если к файлу можно получить доступ через Z: \ path \ b.txt
). Если вам нужно поддержать такое поведение, эти вопросы могут помочь.