Markus Elsken schrieb in <news:517a66d8$0$30113$
8e6e...@newsreader.ewetel.de>
> Am 26.04.13 12:38, schrieb Thomas Kaiser:
>> kextutil -v 1 -b com.sierrawireless.driver.SierraDIPSupport
>
> Mit genau dieser Art von Kommandozeile
Hihi, mit "dieser Art" nur? Nicht mit _jener_? ;-) Im Ernst: Das ist
doch fast immer kryptisch bis hirntot, wie man CLI-Tools aufrufen muß?
Und das, was dann da oft ausgegeben wird, spottet jeder menschlichen
Logik. Wir haben ein CLI-Produkt für 2.000,- Tacken im Portfolio, das
eigentlich nur ein Wrapper um 2 CLI-Tools eines anderen Herstellers ist.
Wohlgemerkt ist das am Ende wiederum ein CLI-Tool, das aber einerseits
simpel und konsistent bedienbar ist und andererseits das tut, was
erwartet wird und nicht andauernd mit Fehlermeldungen abbricht [1]. Da
steckt zwar schon eine riesige Menge an Logik unter der Haube (eben das
"es richtig machen", d.h. automatisch anhand Randbedingungen richtige
Entscheidungen treffen). Aber der eigentliche Clou ist, daß es zwei
ultrakryptische CLI-Tools bedienbar macht (per CLI -- aber das ist auch
sinnvoll so, weil das in diverse Automatisierungslösungen integriert
wird).
Heißt: Das Problem hast Du immer und bei jedem CLI-Tool individuell. Es
gibt welche, die sind gut zu bedienen (im Sinne von: klarer Hilfstext,
logische Schalter, hilfreiche Warnungen/Fehlermeldungen) und es gibt die
aus der Hölle. Und an was Du gerätst, weißt Du vorher nie. Goldene
Regeln: Gucken, ob das Ding eine Manual Page mitbringt:
man kextutil
Dann erstmal nur als unprivilegierter User ausprobieren (keinesfalls als
root oder aus "sudo-Kontext" heraus). Und sich per Websuche einen
Eindruck verschaffen, was das Ding kann und wofür es eingesetzt wird.
Zumal es -- wie im konkreten Fall -- auch Tools gibt, die gleich vor
sich selbst warnen. Aus der Manual Page:
BUGS:
Many single-letter options are inconsistent in meaning with (or directly
contradictory to) the same letter options in other kext tools.
Im konkreten Fall hätteste mir halt vertrauen sollen/müssen :-)
> stehe ich ziemlich auf Kriegsfuss, das ist Unix-Hardcore pur.
Nee, das ist nur ein CLI-Tool, mit dem Du nicht vertraut bist. Das kann
Dich in Umgebungen abseits Unix auch treffen.
> Gibt es irgendwo ein Buch, wo ich mich in diese Materie mal einlesen
> kann?
Puh, keine Ahnung. Da bin ich mit meiner CLI-Vorschädigung (ich hab mit
Batch-Programmierung unter DOS 3.x vor ca. 100 Jahren angefangen) der
falsche Ansprechpartner. Aber ich denke, daß das weniger ein Thema ist,
bei dem man mit Wissen denn eher mit Methodik weiterkommt.
> Eine V2 ist für mich eine übrigens eine Rakete :-)
Das -v ist neben -h einer der ganz seltenen Fälle, in denen ein Schalter
in so ziemlich allen CLI-Tools Identisches bewirkt: -v --> verbose
Ausgabe, schaltet das Tool also geschwätziger hinsichtlich dessen, was
es grad macht. Und "-h" sollte Hilfstexte ausspucken. Und genauso wie
ich im GUI am Mac auf allem Neuen sofort einmal mit gedrückter [alt]-
Taste herumklicke, so kombiniere ich auch sofort -h und -v (ggf.
mehrfach). Immer wieder erstaunlich, wieviele Tools dann massiv Hilfe
spenden.
Aber natürlich bestätigen die Ausnahmen die Regel und "-h" kann auch was
völlig anderes tun als Hilfstexte ausspucken. Und natürlich kann das
gefährlich sein, weshalb man das immer erstmal mit 'nem unprivilegierten
"normalen" Account ausprobiert und 'ne Websuche voranstellt, um eine
Idee dafür zu bekommen, was das Ding macht.
Und zum Thema Gefährlichkeit und "mit GUI wäre das nicht passiert"...
Diese Anleitung hier im Thread, wie man sich einfach so im Finder das
System zerschießen kann (Info-Dialog der Systemplatte aufrufen und
Zugriffsrechte für "jeden" rekursiv der Platte entziehen -- danach
stirbt das System lustig weg und die Kiste bootet nicht mehr bis zum
nächsten "Rechte Reparieren"), basiert auf 'ner wahren Begebenheit.
Ein sehr guter Spezl von mir hat diesen Stunt vor paar Monaten im Urlaub
hingelegt. Hatte sein MacBook Pro dabei, um nebenher zu arbeiten. Dann
saß er eines Abends an der Poolbar, hatte sich schon anständig Cocktails
reingestellt und surfte zusammen mit seiner ebenfalls nicht zu knapp
angeschickerten Holden via Hotel-WLAN im großen weiten Internet.
Dann haben sie wohl irgendwelche Schweinkram-Bilder, die sie gerne mal
voneinander machen, gesichtet und sortiert und sind dabei über den
Finder-Info-Dialog gestolpert. Und dieses Detail mit den Zugriffsrechten:
"Jeder darf zugreifen". JEDER! Auf unsere intimen Bilder. HIER! Promille-
bedingt verschwamm dann die feine Grenze zwischen lokaler Platte, Hotel-
WLAN und dem großen weiten Internet und der Entschluß, diesem skandaläsen
Zustand ein Ende zu bereiten, und "jeden" einfach mal auszuschließen
wurde gefaßt. Und das gleich richtig, also rekursiv. So nahm das Unglück
seinen Lauf, und ich hatte dann in der früh richtig viel zu lachen beim
Durchsehen der ganzen Hilfeschreie per SMS, die von Stunde zu Stunde
ernüchterter ausfielen :-)
Wobei er noch Glück hatte, daß ich ihm erst antworten konnte, als er
schon wieder halbwegs nüchtern war. Mit "Nein, Du kannst jetzt die
nächsten Wochen gar nix machen" und "Ja, mit dieser Recovery Partition,
die Du nicht haben wolltest, wäre das kein Problem" wäre er mit seinen
2,x Promille sicher nicht gut klargekommen und hätte das MacBook Pro
"Feierabend!!" brüllend im Pool versenkt.
Gruss,
Thomas
[1] macbookpro-tk:~ tk$ k-convert
Exactly one inputfile and one outputfile must be specified and at least
one conversion argument.
Usage: k-convert [--format=TIFF|JPEG|BMP|JP2|PNGf|PDF|GIF|EPS]
[--colorspace=None|Grayscale|Indexed|RGB|CMYK|CIELab]
[--renderingintent=0-6] [--compression=0-100] [--xPix=n] [--yPix=n]
[--resolution=n] [--help] inputfile outputfile
k-convert uses Helios' ImageServer and eventually PrintPreview
capabilitites. Currently version UB+ or above is supported.
Both inputfile and outputfile have to be files. Redirection from
pipes or stdin/stdout is not supported. On Windows file/folder paths
can be supplied in Helios' format (/C:/foo/bar) as well as Windows'
style (C:\foo\bar). Please always keep in mind that target file format
and filename suffix should match each other to prevent applications
from being unable to open the files correctly (e.g. Adobe Photoshop).
Options may be:
--format=TIFF|JPEG|BMP|JP2|PNGf|PDF|GIF|EPS
Based on the chosen target image format only some generally supported
color spaces and compression schemes might be available:
BMP (Windows Bitmap File Format) (suffix=bmp)
Colorspaces supported: RGB
Compression schemes supported: None
GIF (Compuserve Graphics Interchange Format) (suffix=gif)
Colorspaces supported: Indexed
Compression schemes supported: LZW
JP2 (JPEG 2000 Fileformat) (suffix=jp2)
Colorspaces supported: Grayscale, RGB, CMYK, CIELab
Compression schemes supported: Wavelet (lossy and lossless)
JPEG (JPEG or JFIF format) (suffix=jpg)
Colorspaces supported: Grayscale, RGB, CMYK, CIELab
Compression schemes supported: DCT (lossy)
PNGf (Portable Network Graphics Fileformat) (suffix=png)
Colorspaces supported: Grayscale, RGB
Compression schemes supported: Deflate
PDF (Portable Document Format) (suffix=pdf)
Colorspaces supported: Grayscale, RGB, CMYK, CIELab
Compression schemes supported: None, DCT/JPEG, Flate/ZIP
TIFF (Tagged Image File Format) (suffix=tif)
Colorspaces supported: Grayscale, RGB, CMYK, CIELab
Compression schemes supported: None, LZW, ZIP
EPS (Encapsulated PostScript File) (suffix=eps,epsf)
Colorspaces supported: Grayscale, RGB, CMYK, CIELab
Compression schemes supported: None, JPEG
Notes: - If you choose solely a new target format with limited
support for colorspaces and the source image's color space
is not supported by the target image format the conversion
will be aborted with an explanative message on stderr
(this might happen eg. with a CMYK TIFF and PNGf as target
format)
--colorspace=None|Grayscale|Indexed|RGB|CMYK|CIELab
If omitted or set to "None" then no colorspace conversion will take
place. For conversions between CMYK and CIELAB/RGB default profiles
will be used in case the source image has no attached/embedded profile.
Otherwise the profile in question will be used.
Notes: - If you supply illegal color spaces (eg. Bilevel for BMPf)
then no color space conversion will be applied.
- When source color space is CMYK and an illegal target color
space or none is supplied then a fallback to RGB as target
colorspace takes place.
- If target format is either JPEG or JPEG2000, source color
space is Bilevel and no target color space is given an
automagic fallback to Grayscale as target color space happens
- "Indexed" is only supported for the GIF format but there's
no need to specify it since it is the only color space
supported.
--renderingintent=0-6
The different numbers have the following meaning:
0 for perceptual,
1 for relative colorimetric,
2 for saturation,
3 for absolute colorimetric,
4 for perceptual with black point compensation,
5 for relative colorimetric with black point compensation or
6 for saturation with black point compensation.
If omitted reasonable defaults will be used for colorspace conversions.
For details see the table below. Please note that YCbCr is the internal
color space of "RGB JPEG" so it could read similar "RGB".
From: \To: Spot RGB Gray CMYK YCbCr CIELab
Spot 1 1 1 0 1 1
RGB 1 1 1 0 1 1
Gray 1 1 1 0 1 1
CMY 1 1 1 1 1 1
CMYK 1 1 1 1 1 1
YCbCr 1 1 1 0 1 1
CIELab 1 1 1 0 1 1
To: Spot RGB Gray CMYK YCbCr CIELab
--compression=0-100
This parameter depends on the chosen image format. "0" means no
compression at all and may not be applicable for all image formats
(eg. JPEG and JPEG 2000). "100" means maximum quality and the actual
impact depends on the image format in question:
BMP: 0-100 --> uncompressed
GIF: Ignored. Always LZW compressed
JP2: 0 --> not applicable. Default compression (90) will be used
1-99 --> lossy compression level
100 --> losless compression
JPEG: 0 --> not applicable. Default compression (90) will be used
1-100 --> JPEG quality level
PNGf: Ignored. Always "Deflate" compressed
PDF: 0 --> uncompressed
1-99 --> lossy JPEG compression level
100 --> losless ZIP/Flate compression
TIFF: 0 --> no compression
1-99 --> LZW ("Compress") compression will be applied
100 --> Grayscale/RGB/CMYK/CIELab: ZIP ("Flate") compression
Bilevel: CCITTG4 will be used
EPS: 0 --> no compression (binary encoding)
1-100 --> JPEG quality level
If --compression will not be supplied on the command line or as an
illegal value (eg. 0 for both JPEG/JP2) a default of 90 will be used.
Depending on the image format in question different behaviour may
occur -- for details see above.
Examples:
- k-convert --format=TIFF --> LZW compressed TIFF
- k-convert --format=TIFF --compression=0 --> Uncompressed TIFF
- k-convert --format=PDF --> JPEG compressed PDF
- k-convert --format=PDF --compression=100 --> ZIP compressed PDF
- k-convert --format=JPEG --compression=0 --> illegal value,
default will be used:
DCT/JPEG high quality
--xPix=n
The image will be downscaled to this specific width in pixels while
maintaing the image's aspect ratio. If a larger value than the actual
image's width will be supplied no upscaling will take place due to
quality reasons. See below for examples and mutual reactions with the
following both parameters!
--yPix=n
Same as "--xPix" regarding the image's height. If both "--xPix" and
"--yPix" will be supplied the parameter matching the source image's
dimensions closer will be used.
Examples: Given a source image with 4000x2000 pix.:
- k-convert --xPix=1500 --> result with 1500x750 pix.
- k-convert --yPix=1500 --> result with 3000x1500 pix.
- k-convert --xPix=1500 --yPix=1500 --> result with 1500x750 pix.
--resolution=n
If --resolution will be supplied and neither --xPix nor --yPix will
be used the source image's resolution will be downscaled to the
resolution supplied with this parameter. Values are interpreted as
pixels per inch (ppi) and currectly no upscaling is supported due to
quality reasons. This means if you supply a value larger than the
source image's resolution no scaling will happen.
The behaviour of this switch changes completely if either --xPix or
--yPix will be supplied on the command line too. In that case a
scaling will be applied based on the pixel dimensions and afterwards
the resolution metadata of the target image will solely be adjusted
to the resolution value without applying any further scaling to the
image. This applies only to TIFF, JPEG or PNG target formats since
other image formats do not support this specific resolution metadata.
Examples: Given a source image with 4000x2000 pix. and 300 ppi:
- k-convert --resolution=150 --> result with 2000x1000
pix., 150 ppi
- k-convert --resolution=72 --yPix=1500 --> result with 3000x1500
pix., 72 ppi
- k-convert --resolution=300 --yPix=1500 --> result with 3000x1500
pix., 300 ppi
--help
Displays this help text