PowerShell, Windows'ta Cygwin kabuğumun yerini almaya hazır mı? [kapalı]

PowerShell'i öğrenmeli miyim, yoksa sadece Cygwin / Perl betikleri / Unix kabuk betikleri vb.

PowerShell'in yararı, komut dosyalarının Cygwin'e sahip olmayan takım arkadaşları tarafından daha kolay kullanılabilmesidir; ancak, o kadar çok genel amaçlı senaryo yazıp yazamayacağımı veya insanların bunları bile kullanıp kullanamayacağını bilmiyorum.

Unix komut dosyaları çok güçlü, PowerShell geçişi garanti edecek kadar yakın mı?

İşte PowerShell'de aradığım belirli şeylerden (veya eşdeğerlerinden) bazıları:

• grep
• çeşit
• uniq
• Perl (PowerShell, Perl'in yeteneklerine ne kadar yaklaşıyor?)
• AWK
• sed
• dosya (dosya bilgilerini veren komut)
• vb.

Araçlar sadece araçlardır.
Yardım ederler ya da yardım etmezler.
Yardıma ihtiyacınız var ya da yok.

Unix'i biliyorsanız ve bu araçlar Windows'ta yapmanız gerekenleri yaparsa - o zaman mutlu bir adamsınız ve PowerShell'i öğrenmenize gerek yoktur (keşfetmek istemiyorsanız).

Benim asıl amacım bir dizi Unix aracını Windows'a dahil etmek ve onunla birlikte yapmaktı (takımdaki birçoğumuzun derin Unix geçmişleri ve bu topluluğa sağlıklı bir saygı dozu var.)

Bulduğum şey, bunun gerçekten fazla yardımcı olmadığıydı. Bunun nedeni AWK / grep / sed'in COM , WMI , ADSI , Kayıt Defteri, sertifika deposu vb.

Başka bir deyişle, UNIX, metin dosyaları etrafında kendi kendini ayarlayan bir ekosistemdir. Bu nedenle, metin işleme araçları etkin bir şekilde yönetim araçlarıdır. Windows, API'ler ve Nesneler etrafında kendi kendini ayarlayan tamamen farklı bir ekosistemdir. Bu yüzden PowerShell'i icat ettik.

Bulacağınızı düşündüğüm şey, metin işlemenin Windows'ta istediğinizi elde etmediği birçok olay olacağı. Bu noktada, PowerShell'i almak isteyeceksiniz. NOT - bu bir ya hep ya hiç anlaşma değildir. PowerShell içinde Unix araçlarınızı çağırabilirsiniz (ve metin işlemlerini veya PowerShell'in metin işlemlerini kullanabilirsiniz). Ayrıca Unix araçlarınızdan PowerShell'i arayabilir ve metin alabilirsiniz.

Yine - burada din yoktur - odak noktamız size başarılı olmanız için gereken araçları vermektir. Bu yüzden geribildirim konusunda çok tutkuluyuz. İşe nereden düştüğümüzü veya ihtiyacınız olan bir aracınızın bulunmadığını bize bildirin ve listeye koyacağız ve buna ulaşacağız.

Dürüst olmak gerekirse, kendimizi 30 yıllık bir delikten kazıyoruz, bu yüzden biraz zaman alacak. Bununla birlikte, Windows Server 2008 / R2 beta sürümünü ve / veya sunucu ürünlerimizin betalarını alırsanız, bu deliğin ne kadar çabuk dolduğunu şok edeceğinizi düşünüyorum.

Kullanımla ilgili olarak - bugüne kadar 3,5 milyondan fazla indirme yaptık. Bu, Windows Server 2008 işletim sisteminde kullanan kişileri içermez, çünkü isteğe bağlı bir bileşen olarak bulunur ve indirmeye gerek yoktur.

V2, Windows'un tüm sürümlerinde gönderilecektir. İsteğe bağlı bir bileşen olduğu Sunucu çekirdeği dışındaki tüm sürümler için varsayılan olarak açık olacaktır. Windows 7 / Windows Server 2008 R2 gönderildikten kısa bir süre sonra, V2'yi Windows XP ve üzeri tüm platformlarda kullanıma sunacağız. Başka bir deyişle - öğrenmeye yaptığınız yatırım çok sayıda makine / ortam için geçerli olacaktır.

Son bir yorum. PowerShell'i öğrenmeye başladığınızda / başladığınızda, bence çok mutlu olacaksınız. Tasarımın çoğu Unix arka planlarımızdan büyük ölçüde etkilenir, bu yüzden oldukça farklıyken, çok hızlı bir şekilde alırsınız (Unix olmadığından küfrettikten sonra).

İnsanların öğrenme için çok sınırlı bir bütçesi olduğunu biliyoruz - bu yüzden tutarlılık konusunda çok zorlandık. Bir şeyler öğreneceksiniz ve sonra tekrar tekrar kullanacaksınız.

Deney! Zevk almak! Tut!

grep

Select-Stringcmdlet ve -matchoperatör normal ifadelerle çalışır. Ayrıca, daha gelişmiş işlevsellik için .NET'in normal ifade desteğinden doğrudan yararlanabilirsiniz.

çeşit

Sort-Object(hatırladığımdan daha güçlü * nix's sort). Rasgele ifadelerde çok düzeyli sıralamaya izin verme. Burada PowerShell'in altta yatan türdeki bakımı yardımcı olur; örneğin bir DateTimeözellik, DateTimebiçimlendirilebilir bir biçimde biçimlendirmeyi sağlamak zorunda kalmadan bir olarak sıralanır .

uniq

Select-Object -Unique

Perl (PowerShell Perl yeteneklerine ne kadar yaklaşıyor?)

Perl'in alana özel destek kitaplıklarının genişliği açısından: hiçbir yerde yakın değil (henüz).

Genel programlama için, PowerShell kesinlikle daha uyumlu ve tutarlıdır ve genişletilmesi daha kolaydır. Metin munging için tek boşluk Perl ..operatörüne eşdeğer bir şeydir .

AWK

AWK kullandığından beri yeterince uzun oldu (18 yaşından büyük olmalı, daha sonra Perl kullandım çünkü), gerçekten yorum yapamam.

sed

[Yukarıyı görmek]

dosya (dosya bilgilerini veren komut)

PowerShell'in burada gücü, dosya sistemi nesneleriyle yapabileceklerinden çok fazla değildir (ve burada tam bilgi alır, uygun şekilde dirdöndürür FileInfoveya FolderInfonesneleri), tüm sağlayıcı modeli budur.

Kayıt defterini, sertifika deposunu, SQL Server'ı, Internet Explorer'ın RSS önbelleğini, vb. Dosya sistemiyle aynı cmdlet'lerin kullanabileceği bir nesne alanı olarak ele alabilirsiniz.

PowerShell, kesinlikle Windows'ta ileriye giden yoldur. Microsoft, gelecekteki ev dışı ürünler için gereksinimlerinin bir parçası haline getirdi. Bu nedenle Exchange'de zengin destek, SQL Server'da destek. Bu sadece genişleyecek.

Bunun yeni bir örneği TFS PowerToys'tur. Birçok TFS istemci işlemi, her seferinde tf.exe'yi başlatmak zorunda kalmadan yapılır (yeni bir TFS sunucu bağlantısı vb. Gerektirir) ve daha sonra verileri daha fazla işlemek daha kolaydır. Tüm TFS istemci API'sine TF.exe'nin Team Explorer'ında gösterilenden daha ayrıntılı bir şekilde geniş erişim sağlar.

Kariyeri 1997-2010 yılları arasında Windows kurumsal gelişimine odaklanan biri olarak, açık cevap daha önce verilen tüm iyi nedenlerden dolayı PowerShell olacaktır (örneğin, Microsoft'un kurumsal stratejisinin bir parçasıdır; Windows / COM / .NET ile iyi entegre olur; ve dosyaların yerine nesnelerin kullanılması "daha zengin" bir kodlama modeli sağlar). Bu nedenle, son iki yıldır PowerShell'i kullanıyordum ve tanıtıyordum, "İnanç Sözü" nü takip ettiğime olan inançla.

Ancak, bir pragmatist olarak PowerShell'in bu kadar harika bir cevap olduğundan artık emin değilim. Mükemmel bir Windows aracı ve Pencere komut satırı olan tarihi deliği doldurmak için çok gerekli bir adım sağlarken, hepimiz Microsoft'un tüketici bilgi işlem kaymasını izlediğinden, Microsoft'un işletim sistemini korumak için büyük bir savaş olması muhtemel görünüyor geleceğin işletmesi için önemlidir.

Gerçekten de, çalışmamın heterojen ortamlarda giderek daha fazla olduğunu bulduğumda, şu anda Bash komut dosyalarını kullanmanın çok daha yararlı olduğunu düşünüyorum, çünkü bunlar sadece Linux, Solaris ve Mac OS X'te değil, aynı zamanda Cygwin'in yardımı - Windows'ta.

Dolayısıyla, OS'nin geleceğinin tekel olmaktan ziyade metalaştırıldığı inancını satın alırsanız, mümkün olduğunda tescilli araçlardan uzak tutan çevik bir geliştirme aracı stratejisini tercih etmek mantıklı görünmektedir. Bununla birlikte, geleceğinizin Redmond'a hükmettiğini görürseniz, PowerShell'e gidin.

Komut dosyası otomasyonu için biraz PowerShell kullandım. Ortamın Unix kabuklarından çok daha fazla düşünülmüş gibi görünse de, pratikte metin akışları yerine nesnelerin kullanımı çok daha karmaşıktır ve son 30'da geliştirilen birçok Unix tesisi yıllar hala kayıp.

Cygwin hala Windows ana bilgisayarları için tercih ettiğim komut dosyası ortamıdır. İşlerin yapılmasında alternatifleri kesinlikle yener.

Burada çok sayıda harika cevap var ve işte benim almam. PowerShell, hazırsanız ... Örnekler:

grep = " Select-String -Pattern "

sort = "Sırala Nesnesi"

uniq = " Benzersiz Olsun "

file = " Get-Item "

cat = " İçeriği Al "

Perl / AWK / Sed komut değildir, ancak yardımcı programlar karşılaştırmak zordur, ancak PowerShell'de hemen hemen her şeyi yapabilirsiniz.

Yakın zamanda PowerShell'de herhangi bir derecede ciddiyetle göz kamaştırmaya başladım. Son yedi yıldır neredeyse tamamen Windows tabanlı bir ortamda çalışmama rağmen, Unix geçmişinden geliyorum ve kendimi sürekli olarak Windows'daki etkileşim deneyimimi "Unix-fy" denemeye çalışırken buluyorum. Az söylemek sinir bozucu.

PowerShell'i Bash , tcsh veya zsh gibi bir şeyle karşılaştırmak adil olur , çünkü grep , sed , awk , find , vb. Gibi araçlar kabuğun bir parçası değildir; ancak her zaman herhangi bir Unix ortamının parçası olacaklardır. Böyle bir PowerShell komutu dedi Seç-dize çok benzer bir işlevi vardır grep ve edilir hatları biraz bulanık olabilir yani ... PowerShell içinde bir çekirdek modülü olarak paketlenmiş.

Bence anahtar şey kültür ve ilgili araç setlerinin kendi kültürlerini somutlaştıracağı gerçeği:

• Unix, dosya tabanlı (genel olarak Unicode olmayan) metin tabanlı bir kültürdür. Yapılandırma dosyaları neredeyse tamamen metin dosyalarıdır. Öte yandan Windows, yapılandırma biçimleri açısından her zaman çok daha yapılandırılmıştır - yapılandırmalar genellikle yönetimi için özel araçlar gerektiren özel veritabanlarında (örn. Windows kayıt defteri) tutulur.

• Unix yönetimsel (ve yıllarca geliştirme) arayüzü geleneksel olarak komut satırı ve sanal terminal olmuştur. Windows bir GUI olarak başladı ve yönetim işlevleri yalnızca son zamanlarda yalnızca GUI tabanlı olmaktan uzaklaşmaya başladı . PowerShell'de sahip olduğu önemli ipucu göz önüne alındığında, komut satırındaki Unix deneyiminin daha zengin, daha olgun bir deneyim olmasını bekleyebiliriz ve deneyimim buna uyuyor. Bu konuda benim tecrübelerime göre:

  • Unix idari deneyimi, en az miktarda tuş vuruşuyla işleri kolaylaştıracak şekilde tasarlanmıştır; bu muhtemelen bir sunucuyu yavaş 9600 baud çevirmeli bağlantı üzerinden yönetmek zorunda kalmanın tarihsel durumunun bir sonucudur. Şimdi PowerShell, oldukça ayrıntılı Verb-Noun standardını dolaşmak için uzun bir yol kat eden takma adlara sahip , ancak bu takma adları tanımak biraz acı verici (herkes daha iyi bir şey biliyor:? alias | where {$_.ResolvedCommandName -eq "<command>"}).

    Tarihin manipüle edilebileceği zengin yolun bir örneği:

    iptableskomutlar genellikle uzun soluklu ve yerleşik tarih manipülasyon birçok düzgün özelliklerden sadece biri için olmasa küçük farklarla onları tekrar bir ağrı olurdu vardır Bash yüzden iptables aşağıdaki gibi kural ekleme:

    iptables -I camera-1-internet -s 192.168.0.50 -m state --state NEW -j ACCEPT

    başka bir kamera için ikinci kez (" camera-2"), yalnızca aşağıdakilerin yayınlanması durumudur:

    !!:s/-1-/-2-/:s/50/51

    hangi vasıta "önceki komutu, ancak yerine gerçekleştirmek -1-ile -2-ve 50ile 51.

  • Unix deneyimi dokunmatik daktilolar için optimize edilmiştir; biri "ev" pozisyonundan ayrılmadan hemen hemen her şeyi yapabilir. Örneğin, Bash kullanarak Emacs tuş bağları (evet, Bash de destekler vi kullanılarak yapılır tarih boyunca bisiklet, bağlama) Ctrl-Pve Ctrl-Nkullanılarak yapılır bir satırın başlangıç ve bitiş hareket ederken Ctrl-Ave Ctrl-Esırasıyla ... ve kesinlikle orada bitmiyor. Ana konumdan hareket etmeden PowerShell konsolundaki en basit navigasyonu bile deneyin ve başınız belada.

  • Unix'te çok yönlü sayfalama ( daha az ) gibi basit şeyler , biraz sinir bozucu olan PowerShell'de kullanıma hazır gibi görünmüyor ve zengin bir editör deneyimi de mevcut değil. Tabii ki, her zaman bu boşlukları dolduracak üçüncü taraf araçları indirebilirsiniz, ancak bu şeyler Unix'in herhangi bir lezzetindeymiş gibi "orada" olsaydı iyi olurdu.

• Windows kültürü, en azından sistem API'leri açısından , her ikisi de son derece yapılandırılmış ve nesne tabanlı olan destekleyici çerçeveler, yani, COM ve .NET tarafından yönlendirilir . Öte yandan, Unix API'lerine erişim geleneksel olarak bir dosya arayüzü ( /devve /proc) veya (nesne yönelimli olmayan) C tarzı kütüphane çağrıları yoluyla gerçekleşmiştir. Komut dosyası oluşturma deneyimlerinin, kendi işletim sistemi paradigmalarına uyması şaşırtıcı değildir. PowerShell doğası gereği yapılandırılmıştır (her şey bir nesnedir) ve Bash -ve-arkadaşlar dosya tabanlıdır. Bir PowerShell programlayıcısının elindeki yapısal API çok geniştir (temel olarak mevcut standart COM ve .NET arabirimleri grubunun genişliğiyle eşleşir ).

Kısacası, PowerShell kodlanabilirliğini tartışmasız daha güçlü olmasına rağmen vardır Bash (.NET kullanılabilirliğini göz önüne aldığınızda BCL ) interaktif deneyim da tümüyle klavye odaklı dan ona geliyorlar, özellikle önemli ölçüde daha zayıf , konsol tabanlı perspektif (birçok Unix kafası gibi).

Hiçbir şekilde çok deneyimli bir PowerShell kullanıcısı değilim, ama maruz kaldığım küçük bir parça beni çok etkiledi. Unix komut isteminde yapabileceğiniz hemen hemen her şeyi yapmak için yerleşik cmdlet'leri birlikte zincirleyebilirsiniz ve CSV'ye, HTML tablolarına dışa aktarma ve daha derinlemesine sistem yönetimi iş türleri için bazı ek iyilikler vardır. .

Ve sed gibi bir şeye gerçekten ihtiyacınız varsa , PowerShell ile oldukça kolay bir şekilde entegre edebileceğiniz her zaman UnixUtils veya GnuWin32 vardır.

Uzun zamandır Unix kullanıcısı olarak, ancak komut adlandırma şemasına alışmakta biraz sorun yaşadım ve daha fazla .NET biliyorsam kesinlikle bundan daha fazla faydalanırdım.

Bu yüzden aslında, sadece Windows özelliği bir sorun yaratmazsa öğrenmeye değer olduğunu söylüyorum.

Kabuk komut dosyalarını seviyorsanız PowerShell'i seveceksiniz!

Microsoft Komut Kabuğu (Ars Technica) rehberli turunda başlayın .

Son denemelerim beni PowerShell ve .NET çağrılarının derinliklerine getirdiğinden, PowerShell'in Cygwin ve Unix kabuğunun yerini alabileceğini söylemeliyim .

Perl hakkında emin değilim, ama hem PowerShell hem de Perl programlama dilleri olarak Turing tamamlandığından, bunu Perl'i değiştirmeye de evet olarak veriyorum.

PowerShell'in * nix altında Cygwin ve sıradan Bash üzerinde sahip olduğu bir şey, korumalı DLL DLL çağrıları gerçekleştirme, işletim sistemini doğrudan API çağrıları, WMI yöntemleri ve hatta COM nesneleri aracılığıyla yönetme yeteneğidir. Internet Explorer'ı kodla başlatmaya, sonra görüntülenen belgeyle istediğinizi yapmaya, bir Web sunucusu için arka ucu etkili bir şekilde taklit etmeye ne dersiniz?

SQL sunucularından ve diğer veri sağlayıcılarından veri toplamaya, ayrıştırmaya ve CSV, posta mesajları, metin ve aslında her türlü mevcut ve mevcut olmayan dosya formatları olarak dışa aktarmaya ne dersiniz? (Elbette alınan verilerden geçerli bir dosya oluşturma becerisi ile, ancak CSV kolayca kullanılabilir).

İmzalı cmdlet'ler ve komut dosyaları, grup ilkeleri ve yürütme ilkeleri aracılığıyla, yönetici olarak çalıştırsanız bile sisteminizde kötü amaçlı kodun çalışmasını önlemeye yardımcı olan ek bir güvenlik vardır.

Hangi komutların uygulandığı hakkında - Richard'ın yanıtı bunları ve PowerShell'in zaten işlevlerini taklit etme yeteneğini listeler.

PowerShell'in geçişi garanti etmek için güçlü olup olmadığı hakkında - bu daha fazla kişisel tercih meselesidir, ancak giderek daha fazla Windows hizmeti onları kontrol etmek için PowerShell cmdlet'lerini sağladığından, mevcut bu hizmetlerle PowerShell'i kullanmamak bir engel olarak kabul edilir. (Hyper-V sunucusu bu tür birincil hizmettir ve ayrıca PowerShell cmdlet'leriyle GUI'den daha fazlasını yapma olanağı sağlar!)

Muhtemelen bu cevap beş yıl gecikmiştir, ancak yine de, birisi Windows'ta idari görevler veya çeşitli şeylerin genel komut dosyalarını uygularsa, kesinlikle PowerShell'i kendi amaçları için kullanmaya çalışmalıdır.

PowerShell'i Cygwin / Perl / Shell kombinasyonuyla karşılaştırdığınızda, PowerShell'in yalnızca bu kombinasyonun "Shell" bölümünü temsil ettiğini unutmayın.

Ancak cmd.exe veya Cygwin'den yaptığınız gibi PowerShell'den herhangi bir komutu çağırabilirsiniz. O mu değil belirtilen fonksiyonları, uygulaması yeniden ve Perl kesinlikle karşılaştırılamaz.

Bu sadece bir kabuk, ama .NET evrenine rahat bir arayüz sağlayarak programlamayı kolaylaştırıyor.

Ayrıca, PowerShell'in Windows XP, Windows Server 2003 veya daha yenisini gerektirdiğini ve BT altyapınıza bağlı olarak bir sorun oluşturabileceğini unutmayın.

Güncelleme:

Cevabımın ne tür bir felsefi tartışmaya yol açacağına dair hiçbir fikrim yoktu.

Cevabımı şu soru bağlamında gönderdim: PowerShell'i Cygwin ve Perl ve Bash ile karşılaştırın.

PowerShell, yerleşik komutlar, komut dosyaları, kullanıcı işlevleri ve harici komutlar (.exe, .bat, .cmd) arasında sözdizimsel bir fark yaratmadığından bir kabuktur. Yalnızca .NET yöntemlerini çağırmak, çağrıya bir ad alanı veya nesne ekleyerek farklılık gösterir.

Programlanabilirliği, PowerShell "diline" özgü herhangi bir şeyden değil, .NET çerçevesinden türetilir.

Bugzilla veya MediaWiki bir web sunucusunda çalışan PowerShell komut dosyaları olarak uygulanır uygulanmaz PowerShell'in bir "komut dosyası dili" olduğuna inanıyorum ;)

O zamana kadar karşılaştırmaların tadını çıkarın .

PowerShell'deki cmdlet'ler çok güzel ve güvenilir bir şekilde çalışıyor. Bir Java / C # geliştiricisi olduğum için nesne yönelimleri bana çok cazip geliyor, ancak tam bir set değil. Nesneye yönelik olduğu için POSIX araç setinin metin akışı olgunluğunun birçoğunda ( awkvesed birkaçını belirtmek için) .

POSIX araçlarında OO tekniklerini ve olgunluğu sevmek ikilemine bulduğum en iyi cevap her ikisini de kullanmak! PowerShell'in harika bir yönü, nesneleri standart akışlara mükemmel bir şekilde bağlamasıdır. PowerShell varsayılan olarak, nesnelerini taşımak için bir nesne boru hattı kullanır. Bunlar standart akışlar değildir (standart çıkış, standart hata ve standart giriş). PowerShell, çıktıyı nesne boru hattı olmayan standart bir işleme geçirmesi gerektiğinde, önce nesneleri bir metin akışına dönüştürür. Bunu çok iyi yaptığı için PowerShell, POSIX araçlarını barındırmak için mükemmel bir yer!

En iyi POSIX araç seti GnuWin32'dir . Yüklenmesi 5 saniyeden uzun sürüyor, ancak sorun olmaya değer ve anlayabildiğim kadarıyla c:\windows\*, dosyaları belirttiğiniz dizinlere kopyalamak dışında sisteminizi (kayıt defteri, klasörler vb.) Değiştirmez . Bu çok güzel çünkü araçları paylaşılan bir dizine koyarsanız, birçok kişi aynı anda bunlara erişebilir.

GnuWin32 Kurulum Talimatları

Exe'yi ( SourceForge sitesinden ) indirin ve uygun bir dizine (kullanacağım) işaret ederek yürütün C:\bin. GetGnuWin32Orada çalıştıracağınız bir dizin oluşturur download.bat, daha sonra install.bat(parametreler olmadan), bundan sonra C:\bin\GetGnuWin32\gnuwin32\binbir Windows makinesinde var olan en yararlı klasör olan bir dizin olacaktır . Bu dizini yolunuza ekleyin, artık başlamaya hazırsınız.

TL; DR - Windows veya PowerShell'den nefret etmiyorum. Sadece olamaz do Windows veya PowerShell şey.

Şahsen hala en iyi ihtimalle PowerShell'i ezici buluyorum.

• dizin yollarının sekme tamamlanması birleşmez ve kullanıcının her ad tamamlandıktan sonra bir yol ayırıcı girmesini gerektirir.
• Windows bile bir yolun veya bir yol nedir kavramını yok gibi ben hala hiçbir erişilebilir kullanıcı ana göstergesi olan, hissetmek ~/bazı kısa@environment://somejibberish/%user_home%

• NTFS hala bir karmaşa ve görünüşte her zaman olacak. İyi şanslar.

• cmd-esque arabirimi, dinozor cmd.exe, PowerShell, Düzenle → İşaretle hala bilgileri kopyalamanın tek yolu olmak ve yalnızca görünür terminal alanının dikdörtgen blokları şeklinde kopyalamak için görünür. ve Düzenle → Mark hala dizeleri terminale yapıştırmanın tek yoludur.

• Mavi boyamak, onu daha çekici yapmaz. Yine de Microsoft geliştiricilerinin renkli bir tada sahip olmalarına aldırmıyorum.

• Windows her zaman ekranın sol üst köşesinde açılır. Dikey görev çubukları kullanan biri için, özellikle Windows görev çubuğunun pencerenin kopyalama / yapıştırma işlevine erişim sağlayan tek köşesini kapsayacağı düşünüldüğünde inanılmaz derecede can sıkıcıdır.

Windows'un içerdiği araçların gerekçesiyle fazla konuşamam. Bir dizi açık kaynaklı, özgürce lisanslanan CLI araçları olduğu ve PowerShell'in bildiklerime göre, hiçbiri mutlak bir hayal kırıklığı değildir.

• PowerShell wget, görünüşe göre GNU wget ile karşılaştırılamaz argümanlar alıyor. Teşekkürler, portably yararsız umut ışıltısı.
• PowerShell POSIX, Bash uyumlu değildir, özellikle &&operatör ele alınmaz, bir şeyden sonra koşullu komutun en basitini yapar.

Adamı tanımıyorum; Denedim, gerçekten yaptım; Yine de bir dahaki sefere açtığımda daha az işe yaramayacağı umuduyla bir şans vermeye çalışıyorum. PowerShell'de hiçbir şey yapamıyorum ve GNU araçlarını Windows'a getirmek için gerçek bir projeyle zar zor şeyler yapabiliyorum.

MySysGit bana dinozor cmd.exe istemini birkaç GNU aracıyla veriyor ve hala çok ezici, ama son yol tamamlandığında çalışıyor. Git komutu Git Bash'te çalışacaktır.

MySysGit için Mintty, Cygwin arayüzünü mysysgit ortamı üzerinde verir, kopyalayıp yapıştırır (kopyalamayı (fare), yapıştırmak için Shift+ Insmodernliği ...) seçer . Ancak, git pushMintty'de gibi şeyler bozuldu.

Ben rant demek istemiyorum, ama yine de Cygwin gibi araçlar bile Windows üzerinde komut satırı kullanılabilirliği ile ilgili büyük sorunlar görüyorum.

Not: PowerShell'de bir şey yapılabileceği için, kullanılabilir değil . Kullanılabilirlik yetenekden daha derindir ve bir ürünü tüketici olarak kullanmaya çalışırken odaklandığım şeydir.

En azından henüz, PowerShell'in gerçekten kalktığını görmedim. Bu nedenle, ekibinizdeki diğerleri zaten bilmediği sürece onu öğrenme çabasına değmeyebilir.

Tahmininiz için, başkalarının geride bırakabileceği bir betik diliyle, bahsettiğiniz gibi Perl veya Ruby veya Python gibi diğerleriyle daha iyi olabilirsiniz.

Bence bunların çoğu ne yapmanız gerektiğine bağlı. Şahsen Python'u kendi kişisel senaryolarım için kullanıyorum, ama asla aktaramayacağım bir şey yazmaya başladığımda biliyorum - bu yüzden çok devrimci bir şey yapmamaya çalışıyorum.

Neden her ikisini de kullanmıyorsunuz? Perg gibi yorumlanmış diğer komut dosyaları gibi Cygwin'deki PowerShell komut dosyalarını çağırın.

Bunu yeterince yapmak için https://bitbucket.org/jbianchi/powershell'i bir Bash sarıcısının Cygwin'deki powershell.exe'yi çağırması için yazdım . Bu bir olarak kullanılabilir shebang bir powershell.exe .ps1 senaryonun ilk satırı olarak (PowerShell da bir yorum olarak "#" kullanan beri). Örnekler için bkz. Https://bitbucket.org/jbianchi/powershell/wiki/Ana sayfa

Birkaç satırda Cygwin ve PowerShell farklı araçlardır, ancak Cygwin yüklüyse Cygwin yürütülebilir dosyalarını bir PowerShell oturumu içinde çalıştırabilirsiniz. PowerShell'e artık alıştım, artık grep, sıralama, awk vb.

Kendimi kullandığım ana araç ssh.exe, ancak bir PowerShell oturumu içinde.

Harika çalışıyor.

PowerShell programlamanın çabaya değmeyeceğini gördüm.

Unix altında kabuk komut dosyası oluşturma konusunda birkaç yıllık tecrübem var, ancak PowerShell ile her şeyi yapmanın çok zor olduğunu gördüm.

Birçok işlev, Windows Yönetim Arabirimini sorgulamanızı ve ihtiyacınız olan bilgileri elde etmek için SQL benzeri komutlar vermenizi gerektirir.

Örneğin, bir dizin ağacından belirli bir soneki olan tüm dosyaları kaldırmak için bir komut dosyası yazmak istedim . Unix altında bu basit olurdu ...

find . -name \*.xyz -exec rm {} \;

Birkaç saat ile gevezelik sonra Scripting.FileSystemObjectve WScript.Shellve veren '& sürücüye & 'AND Path = '' & SearchFolder & "'", nihayet vazgeçti "Win32_ShortcutFile Sürücü =" SELECT * FROM' ve Windows Explorer'ın için yerleşmiş Arama komuta ve sadece elle yapın. Muhtemelen istediğimi yapmanın bir yolu var, ama açık bir şey görmedim ve MSDN sitesindeki tüm örnekler değersiz olacak kadar önemsizdi.

EDIT Heh, elbette bunu yazdığım anda biraz daha etrafa dürttüm ve eksik olduğumu buldum: -recurseitem kaldır komutunun seçeneği hatalı (eğer kullanırsanız ortaya çıkar get-help remove-item -detailed).

"Remove-item -filter '* .xyz' -recurse" deniyordum ve işe yaramadı, bu yüzden vazgeçtim.

Kullanmanız gerektiği ortaya çıkıyor get-childitem -filter '*.xyz' -recurse | remove-item

Https://github.com/skanga/BashWin adresindeki BashWin'i kullanarak Windows'ta Bash komut dosyalarını çalıştırmayı da deneyebilirsiniz .

PowerShell, çok güçlü, Unix kabuklarının standart yerleşiklerinden daha güçlüdür (ancak yalnızca alt programlara genellikle dahil edilen işlevselliğin çoğunu içerdiği için). Ayrıca, IronPython , IronRuby , PerlNet, vb.Dahil olmak üzere herhangi bir .NET dilinde uygulama yazabileceğinizi veya Cygwin komutlarınızı PowerShell'den çağırarak tüm ekstra işlevleri yok sayarak düşünebilirsiniz ve Bash, KornShell , ya da her neyse...