2012-05-30 3 views
16

W .NET możemy łatwo uzyskać dostęp do argumentów podziału wiersza poleceń w tablicy ciągów z argumentu Main(string[]) lub Environment.GetCommandLineArgs(). Czy istnieje jednak sposób na uzyskanie niezainfekowanej linii poleceń jako jednego ciągu?Uzyskiwanie nieprzetworzonej (nieokreślonej) linii poleceń w .NET

Tło: moja aplikacja dodaje się do menu kontekstowego FileExplorer (jak robi to Notepad ++). Kiedy jest uruchamiany w ten sposób, nazwa pliku jest przekazywana bez cytowania, co oznacza, że ​​jeśli na ścieżce znajdują się spacje, jest ona zepsuta. Wiem, że mogę to naprawić, obejmując %1 w cudzysłowie w rejestrze, jak myapp.exe "%1", ale kiedy sprawdzam rejestr innych aplikacji, nie robili tego. Są proste jak notepad.exe %1 - mają kompletną linię poleceń. Chcę wiedzieć, czy jest to możliwe w .NET i jak.

Odpowiedz

22

Spróbuj użyć Environment.CommandLine

+0

Czy istnieje sposób na łatwe usunięcie nazwy pliku wykonywalnego? –

+1

@JaredBeach, .Replace (Application.Executable Path, "") –

4

Spróbuj:

Environment.CommandLine

to lepiej zrobić to do 30 znaków.

3

Aby uzyskać nieprzetworzoną, nieprzetworzoną, niezmienioną linię komend, należy P/Invoke GetCommandLine z kernel32. Niektóre analizy będą wykonywane przez system operacyjny. Na przykład przekierowanie IO, takie jak >foo.txt, zostanie wykluczone z tekstu wiersza poleceń, niezależnie od użytej techniki.

Środowisko.CommandLine może być wystarczająca, ale należy pamiętać, że usuwa spacje pełnoekranowe między argumentami (chyba że sam argument jest ujęty w cudzysłów) i usuwa cytaty z cytowanych argumentów.

Na przykład, w wierszu poleceń:

test.exe this is "a test"

Environment.CommandLine wynosi: "this is a test"

Ale rentowności GetCommandLine: "test.exe this is "a test"" ze spacjami i cytaty nienaruszony, wraz z ścieżka exe.

Uwaga, że przy użyciu tej techniki, trzeba ręcznie analizować tekst wiersza poleceń, które mogą obejmować zdzierając ścieżkę do pliku EXE, który sam może być w cudzysłowach, jeśli ścieżka zawiera spacje.

+1

Huh, nie pokazuj zachowania, które opisujesz. 'Environment.CommandLine' pasuje do' PInvoke' we wszystkich przypadkach, które próbuję. –

+0

Też otrzymuję ten sam wynik z 'Environment.CommandLine' jak z PInvoke w .NET 4.5.2. – DeCaf

+0

Masz rację. Oba dają takie same wyniki w mojej obecnej konfiguracji systemu. Nie znalazłem przykładowej aplikacji i systemu, który testowałem (było to rok temu), ale jeśli kiedykolwiek był uszkodzony, musiał pochodzić ze starszej wersji zestawu .NET + kompilatora niż obecny. Może to dotyczyć na przykład tylko starszej aktualizacji VS. Nie jestem pewien, które wersje. Kiedy dostanę szansę, spróbuję dowiedzieć się, które wersje użyłem. Niezależnie od tego masz rację, że nie jest to oczywiste w obecnym oprogramowaniu. Może w pewnym momencie pojawił się błąd? Nie mogę stwierdzić, że w pewnym momencie nie było to prawdą. Dzięki. – Wyck