Newsgroup: it.comp.os.dibattiti
Titolo: RC1 della PowerShell per Windows (Monad)

Visto che ogni tanto su questo gruppo si dibatte di shell vi segnalo la RC1 
della PowerShell per Windows (nome in codice Monad). Gira anche su XP.
http://www.microsoft.com/windowsserver2003/technologies/management/powershe
ll/default.mspx
Vi consiglio di leggere il documento Getting Started. E' interessante il 
concetto di object pipelines e di cmdlet. La cosa veramente seccante sono 
le 220 pagine di guida utente! 
Massimo Santin

Massimo Santin ha scritto:

ah finalmente si comincia a vedere la famosa Monad....non credo però la
ficcheranno in Vista

 la ficcheranno in Vista
Alcuni fatti sono interessanti: 
1. in realtà la shell gira su .NET 2.0 e quindi la versione di Windows è 
relativamente irrilevante. 
2. Exchange 2007 (e anche la prossima versione di MOM) si amministreranno 
con questa shell (le GUI dovrebbero essere dei front end)
3. è una RC1 cioè una Relase Candidate quindi finalizzata e molto vicina al 
rilascio.
Quindi probabilmente la rilasceranno con Vista. Se non sarà sul DVD di 
installazione probabilmente sarà scaricabile come feature pack aggiuntiva 
(hanno fatto così anche con diverse funzionalità di Windows 2003).
Vedremo. 
MS

 le 220 pagine di guida utente! 
Capisco. Per un "sistemista" windows 220 pagine sono veramente troppe.
-- 
Massimiliano

 il software, aggiornare il sistema, cambiare le configurazioni.
Veramente è già cosi da un bel pezzo.
Saluti.

 Veramente è già cosi da un bel pezzo.
netsh ha 7 anni, è vero, ma non è che sia proprio il massimo, vero ?

Di Korn shell ce ne sono diverse (anche una di Microsoft su 2003 quindi 
non avrebbero problemi in tal senso). Di bash esistono vari porting. 
Quello che comunque fa una bash o una ksh lo fai già da tempo e in vari 
modi su Windows. 
Invece la parte veramente innovativa di psh è la pipe di oggetti: 
veramente interessante. In pratica anzichè avere una coda di caratteri 
(byte) come succede con una pipe stile UNIX ti ritrovi ad avere una coda 
di oggetti. Su questi oggetti puoi chiamare i metodi (funzioni membro) e 
ottenere una coda di nuovi oggetti risultati dei metodi. Ad esempio uno 
script del genere
    	Get-Process | foreach { $_.ProcessName, $_.ID, 
$_.get_PeakVirtualMemorySize() }
mostra nome, id e memoria virtuale massima utilizzata per ogni processo 
attivo. La prima parte del comando (Get-Process) crea una pipe di oggetti 
di tipo processo. La seconda parte preleva ogni processo dalla pipe e lo 
interroga creando una nuova pipe di stringhe (oggetti di tipo stringa su 
cui puoi usare i metodi della classe String presente in .NET).
Si potrebbero fare altre cose come ad esempio killare ogni processo che 
utilizza una certa quantità di memoria e che si chiama in un certo modo. 
La cosa "forte" è che utilizzi metodi adatti alle entità che vai a 
manipolare. Con una shell tradizionale ti ritrovi a passare per stringhe 
e per comandi specializzati. Ad esempio per manipolare un processo 
dovresti recuperare l'id del processo (stringa) e poi utilizzare altri 
comandi di gestione del processo. Con psh recuperi l'oggetto stesso e lo 
manipoli direttamente (a onor del vero un oggetto di tipo processo è un 
wrapper all'entità processo del sistema operativo ma dal punto di vista 
dello scripting non te ne accorgi). 
Riguardo all'esempio di prima si potrebbe anche scrivere così:
    	Get-Process | foreach { $_.ProcessName, $_.ID, 
$_.PeakVirtualMemorySize }
Prima avevo utilizzato esplicitamente il getter della proprietà 
PeakVirtualMemorySize proprio per evidenziare il fatto che stavo 
chiamando un metodo (funzione membro). 
Anche il modello di estensione di psh non sembra male. 
Tutte queste funzionalità poggiano su .NET Framework 2.0 e quindi la 
shell potenzialmente potrebbe sfruttare tutto quello che è presente nel 
framework.
Ti consiglio di provare questa shell con occhi innocenti e non prevenuti.    
Quanto alle 220 pagine... il commento era dovuto al fatto che non la puoi 
apprezzare subito se non ti leggi almeno una parte del manuale. 
MS

 relativamente irrilevante. 
Purtroppo su Windows2000 l'installer non prosegue dicendo che ci vuole 
XP Sp2 o 2003 Sp1.
-- 
Vincenzo

 framework.
E questo mi spaventa. Vedo all'orizzonte nuovi strumenti che non
verranno sfruttati appieno dai buoni perché troppo complessi ma che
verranno sfruttati appieno dai cattivi perché troppo potenti.
Aspettiamo.
-- 
Flavio Visentin
Membro del CICAP
Comitato Italiano per il Controllo delle Affermazioni di P4

 
Il pipe e' un un modo per superare un limite dei processi stream 
oriented. Ma se vuoi gestire una lista di oggetti perche' usare "| 
foreach"? Dal punto di vista puramente sintattico mi sembra piu' 
espressivo (o consueto :-) un
for _ in (Get-Process) { $_.ProcessName, $_.ID, 
$_.get_PeakVirtualMemorySize() }
Sbaglio? Nell'esempio che hai proposto l'uso del pipe mi sembra un solo 
un inutile ammiccamento allo "stile unix".
Alessandro.

 verranno sfruttati appieno dai cattivi perché troppo potenti.
che stronzata! e' come dire che la ferrari non ha motivo di
esistere, perche' troppo potente per un principiante e troppo
pericolosa per chi la sa portare al limite.
ma per favore, nessuno sara' obbligao ad usarla e chi e'
troppo imbranato continuera' ad usare la bash. 

Le tue obiezioni non le condivido: in effetti nella guida dicono: 
  we wanted to be sure that we built an interactive 
  environment first, and foremost, rather than a "scripting" 
  or "programming" environment.
Dalla mia breve esperienza devo dire che, pur non essendo ancora molto 
pratico, PS è molto buona ed efficace. Direi che non mi fa rimpiangere la 
bash neppure sull'interattivo pur con le debite differenze di modello tra 
Linux e Windows. La completition sembra buona (ma è migliorabile) e, una 
volta capita la filosofia, i comandi sono semplici e lineari.  Poi ci sono 
un bel po' di alias predefiniti (tipo ps, ls, cd, dir, pwd).
 
Nella user guide si trova delle appendici che fanno dei paralleli con altri 
ambienti (vbscript, ksh). Anche da queste si capisce bene che è una shell e 
non un linguaggio di scripting.
BTW i cattivi sono tenuto fuori grazie agli onnipresenti certificati 
digitali (a proposito: tra i provider ce ne è uno per gli store dei 
certificati). Nulla si può però contro gli ignoranti e gli stupidi.
MS

 Nulla si può però contro gli ignoranti e gli stupidi.
Su questo invece siamo d'accordo ed è ciò cui facevo riferimento.


 wrote in
news:449e...@newsgate.x-privat.org
: 

Ho usato un esempio forse troppo semplice. Comunque in un classico pipe 
puoi avere N step del tipo A|B|C|...|N. Con la sintassi da te indicata 
sarebbe meno utilizzabile da linea di comando (in pratica si 
programmerebbe). Non è un ammiccamento allo stile UNIX (di cui comunque 
non mi lamento visto il mio personale retaggio) ma una necessità. 
Ad esempio il comando
  Get-Process | where { $_.Name -eq "WINWORD" } | Kill
uccide tutte le istanze di word presenti nella macchina. Mi sembra 
elegante.
Supponiamo invece in un ambiente ipotetico di dover bloccare tutti gli 
account degli utenti la cui casella di posta ha superato una certa 
dimensione e di dover mandare una tabella contenente l'elenco con il nome 
utente, il nome della casella e la dimensione. Supponendo che ogni 
casella sia rappresentata da un oggetto di tipo MailBox con le proprietà 
UserName, Address, Size e con un metodo Block() per bloccare la casella.
Si potrebbe scrivere una cosa del genere:
  Get-ChildItem "<contesto del server di posta>" 
    	| where   { $_.Size  -gt <dimensione massima mail box> } 
    	| Block 
    	| Format-Table UserName, Address, Size 
    	| SendMail "utenti bloccati" 
amminis...@miodominio.it
In effetti penso si possa già fare una cosa del genere per i file. Notare 
che in questo ipotetico scenario si lavora con un pipe di oggetti di tipo 
MailBox fino al comando Format-Table. Il comando Format-Table preleva le 
proprietà degli oggetti MailBox e crea una serie di stringhe in forma 
tabellare utilizzando le proprietà degli oggetti stessi. Da quel momento 
in poi la pipe contiene stringhe.
Lo trovo semplice ed efficace. 
MS

 Lo trovo semplice ed efficace. 
Io non lo trovo assolutamente semplice (l'efficacia non è valutabile);
sarà che sono per la classica programmazione funzionale, ma mi pare
difficltoso capire COSA il frammento di programma faccia.
Preferisco un classico ciclo for con if annidato che invoca un programma
specializzato.


 comandi di gestione del processo.
Palle: 'pgrep', 'pkill' e compagnia cantante esistono da secoli ;)
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
  printf $i }'; echo

 difficltoso capire COSA il frammento di programma faccia.
Scusa ma poco fa criticavi il fatto che la shell somigliava troppo ad un 
linguaggio di scripting. Adesso dimostro il contrario e non ti va bene.
Un comando del tipo
  ps -e | grep "vi" | awk '{ print $1 }' | xargs kill -9
non mi pare più (o meno) intuitivo di
  get-process | where { $_.Name -eq "WINWORD" } | kill
o di (forma abbreviata)
  ps "WINWORD" | kill
Comunque puoi sempre usare una sintassi più funzionale se vuoi. 
MS
P.S.: Killall in questo contesto non c'entra. Anche Windows ha comandi 
più rapidi.



ma infatti, vista la versatilita` di questi strumenti grafici, vedo
miriadi di utenti windows che aggiungono stampanti, utenti tramite queste
fantomatiche shell. 
Piuttosto, perche` la gente in unix continua ad aggiungere gli utenti
dalla linea di comando, nonostante i tool grafici siano affidabili ....?


 difficltoso capire COSA il frammento di programma faccia.
Se l'ho capito financo io.... 

 Palle: 'pgrep', 'pkill' e compagnia cantante esistono da secoli ;)
Non è questo il punto. Comandi simili e per fare le cose che tu hai 
descritto prima ci sono già da tempo anche in Windows. Lo scripting pure. 
Il problema è la consistenza. PS è un sistema estensibile e tutti i 
sistemi Windows (Exchange, SQL Server, SharePoint, MOM, ecc.) 
potenzialmente lo potranno utilizzare. L'utente avrà una shell con una 
interfaccia consistente. Exchange 2007 lo utilizzerà di sicuro.
MS

 Sono perplesso: queste cose le fai già ora senza utilizzare PS. 
Stavo per rispondere la stessa cosa. L'unica pecca è che non è tutto
abbastanza documentato ma so anche io che non sono un utente windows
attivo da parecchio che ste cose le fai anche da cmd line.
-- 
Lawrence - 
http://www.oluyede.org/blog
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier

 queste fantomatiche shell.
Sarà forse per il fatto che la totalità delle installazione che hai visto 
erano
con un numero di utenti basso?
Saluti.

   get-process | where { $_.Name -eq "WINWORD" } | kill
Perdonami, ma mi sembra MOLTO differente. In un caso connetto stdout con
l'stdin di un altro comando, e si tratta di semplici stringhe.
Nell'altro caso, da quanto hai detto, passi in una pipe riferimenti ad
oggetti, cosa che non mi sembra propriamente da shell.


 oggetti, cosa che non mi sembra propriamente da shell.
UNIX č un sistema operativo orientato ai caratteri (cioč byte sulle nostre 
macchine). Il file system č orientato ai caratteri. Negli anni 70 quando č 
nato altri sistemi erano orientati al record. L'idea della pipe di 
caratteri č naturale in UNIX.
Windows (con il .NET Framework) sta evolvendo sempre piů verso un sistema 
con una interfaccia ad oggetti. In questo contesto l'idea di una pipe di 
oggetti mi sembra naturale. WinFS (un file system relazionale ad oggetti) 
sarebbe anch'esso ben inquadrato in questo contesto (peccato l'abbiano 
eliminato - spero che a qualcuno venga il mal di pancia per questo).
MS

 
onestamente anche a me non sembra molto semplice, però sono cmq soddisfatto
del risultato, è sempre meglio di cmd.exe o command.com... cmq faccio una
domanda un po' assurda ma fino ad un certo punto: visto che richiede il
.NET, potrà girare anche sotto linux attraverso mono? :-P

 Sono perplesso: queste cose le fai già ora senza utilizzare PS. 
Sono ancora piu` perplesso: per 20 lunghi anni Microsoft non e` riuscita a
documentare il comando: 'fdisk /mbr', niente, nessun help online, ... e
'fdisk /?' non diceva niente. Pertanto e` immaginabile che in windows si
possano fare cose che nessuno immagina nemmeno. 
Esiste quindi un problema di non riuscire ad avere accesso a queste
informazioni.


   ps -e | grep "vi" | awk '{ print $1 }' | xargs kill -9
sucsa ma: "pkill -9 vi" ti fa schifo?




proprio il contrario: 1000 server unix e 50mila utenti.
Proprio in questo caso mi torna utile poter scriptare il tutto in modo
semplice.


 informazioni.
Il problema a cui tu ti riferisci in realtà è dovuto alla scarsa conoscenza 
delle risorse che ci sono a disposizione. Succede lo stesso con il software 
IBM. 
Ogni buon sistemista Microsoft (non è un ossimoro ;-) ) sa che esistono 
delle fonti di informazione notevoli. In particolare Technet e il sito del 
supporto fanno parte dei tool fondamentali. Inoltre MS pubblica una serie 
di manuali e white papers molto approfonditi scaricabili dai loro siti. 
Infine MS PRESS pubblica libri sui prodotti.
Poi esistono, come in tutti i sistemi, delle particolarità che, in teoria, 
sono presenti solo per il debug del prodotto e che quindi non sono a 
disposizione dell'utente finale.
Del resto molte altre aziende fanno lo stesso. IBM è fra queste ma ha in 
più però il fatto che i Redbook sono gratis.
Riguardo all'FDISK ti consiglio di verificare l'articolo della knowledge 
base che trovi qua
 
http://support.microsoft.com/kb/69013
MS

 Infine MS PRESS pubblica libri sui prodotti.
Capisco e concordo con quello che dici ma un "man comando" con tutti i
dettagli pare brutto?


 dettagli pare brutto?
La PowerShell ce l'ha. Comunque quello che ti serve è l'help di sistema 
(molti lo trascurano) e i DVD del Technet. Installare questi ultimi è un 
po' come installare i file di man o l'info di altri UNIX.
Poi tieni presente che i vari Support Tools, Resource Kit ecc. hanno i loro 
file di help. 
MS

 file di help. 
Ok, era per informazione. Windows lo vedo solo ogni tanto :-)
Anche se in sti giorni pure troppo :-P


 file di help. 
mi sembra un po` eccessivo per sapere cosa fa 'fdisk'


 mi sembra un po` eccessivo per sapere cosa fa 'fdisk'
FDISK è tecnologia di altri tempi e la funzionalità /MBR era dedicata al 
supporto tecnico. Ma mi pare che su qualche documento di IBM ci fosse.
I DVD servono per oggi (permetti che il sistema Windows è un po' più 
sofisticato di DOS). 
Comunque il punto che voglio trasmettere è un'altro: di documentazione ne 
hai a iosa. Il problema semmai è che non riesci a leggerla tutta (per 
fortuna che esistono i motori di ricerca).
Stessa cosa con il software IBM.

 i DVD del Technet.
Ma adesso sono gratuiti?
Fino a qualche anno fa per averli dovevi avere una sottoscrizione a
pagamento, che ti veniva regalata quando diventavi MCP.


 proprietà degli oggetti MailBox e crea una serie di stringhe in forma 
for i in /var/spool/mail/*; do
	filesize=$(ls -la $i|awk '{print $5}')
	user=$(basename $(echo $i))
	if [ $filesize -gt 123456789 ]; then
	   do_something_with $user
	fi
done
il tutto e` molto piu` generico e adattabile a qualsiasi esigenza e, 
soprattutto, non necessita di "oggetti" creati ad-hoc, che probabilmente 
funzionano solo con Exchange Server.


pagamento, che ti veniva regalata quando diventavi MCP.
No, l'abbonamento a Technet Plus non è gratuito, costa sui 640 euro
all'anno. L'abbonamento a Technet Standard circa 450 euro.
Qualche anno fa anche per chi conseguiva la certificazione di MCSE c'era
uno sconto del 50% sull'acquisto, ora non so...
-- 
Rossano Orlandini

 probabilmente funzionano solo con Exchange Server.
Ma questo codice funziona solo con sistemi di posta basati su file. Il 
modello è adatto ai file ma non ad altri scenari. E' meno generico di un 
modello ad oggetti. PS tratta allo stesso modo file, registry, store di 
certificati, ecc. Io ho portato l'esempio di un sistema di posta ma si 
può espandere a cose diverse (ad esempio ad un database server).
Il punto è: un modo uniforme di lavorare con le entità presenti nel 
sistema. Questa shell si basa su questo principio.

 
no caro °le entita' presenti sul sistema° non vuol dire 
"solo_ed_esclusivamente microsoft exchange", perche' e' chiaro che 
quegli oggetti funzionano solo con una entita' presente sul sistema.


 all'anno. L'abbonamento a Technet Standard circa 450 euro.
traduzione:
per sapere che esiste 'fdisk /mbr' io devo pagare 500 euro l'anno.



::: wrote:
:::
:::: Massimo Santin wrote:
::::: i DVD del Technet.
:::: Ma adesso sono gratuiti?
:::: Fino a qualche anno fa per averli dovevi avere una sottoscrizione a
:::: pagamento, che ti veniva regalata quando diventavi MCP.
:::
::: No, l'abbonamento a Technet Plus non è gratuito, costa sui 640 euro
::: all'anno. L'abbonamento a Technet Standard circa 450 euro.
::
:: traduzione:
:: per sapere che esiste 'fdisk /mbr' io devo pagare 500 euro l'anno.
Beh, i contenuti di Technet sono disponibili gratuitamente su internet.
Se uno ha la pazienza (e magari sa scrivere un po di codice) può anche 
scariscarsi tutta la Technet-

 Stessa cosa con il software IBM.
ma neanche per idea. Le man page di Aix sono tra le piu` esaustive nel
mondo Unix, sicuramente piu` complete di quelle per Linux. La
documentazione on-line di IBM inoltre e` qualcosa di paragonabile a
wikipedia.


scariscarsi tutta la Technet-
Esatto.
-- 
Rossano Orlandini

 Beh, i contenuti di Technet sono disponibili gratuitamente su internet.
Fino a qualche anno fa (ovvero fin quando mi occupavo di MS), non tutti
i contenuti della TN c'erano su Internet, e comunque la loro fruibilità
era nettamente diversa (in effetti nella TN su Internet non si trova mai
un cavolo).
Se così non fosse come sarebbero giustificabili i 500 euros?


 quegli oggetti funzionano solo con una entita' presente sul sistema.
Non sono sicuro di aver ben capito cosa vuoi dire. 
Per rafforzare il mio concetto (che devo aver espresso male) si deve 
notare che attualmente la PS lavora  su un certo numero di provider. Con 
il comando Get-PSProvider ne ottieni la lista:
Name                 Capabilities                  Drives
----                 ------------                  ------
Alias                ShouldProcess                 {Alias}
Environment          ShouldProcess                 {Env}
FileSystem           Filter, ShouldProcess         {C}
Function             ShouldProcess                 {Function}
Registry             ShouldProcess                 {HKLM, HKCU}
Variable             ShouldProcess                 {Variable}
Certificate          ShouldProcess                 {cert}
FileSystem, Certificati, Registry sono alcuni provider per entità Windows 
stranote. Il mio esempio Exchange era un esempio e basta. Nulla vieta di 
aggiungere altri provider. L'uniformità del modello è conservata. Puoi 
manipolare tutte le entità raggiungibili tramite i provider in modo 
uniforme. 
Ad esempio
    	Get-ChildItem C:\TEMP
crea un pipe di oggetti che rappresentano gli item in una directory (File 
e Directory). Il sistema poi trasforma la pipe in una rappresentazione 
testuale mostrando gli attributi degli oggetti.
Il comando
 
    	Get-ChildItem HKLM:\SOFTWARE
crea una pipe di oggetti RegistryKey. BTW ls o dir sono alias del comando 
Get-ChildItem. Esempio più concreto: se vuoi cancellare un file contenuto 
in una directory nella PS procedi in questo modo (CD e DEL sono alias e 
CD esegue anche il cambio disco).
    	CD C:\TEMP
    	DEL PIPPO.ZIP
Se vuoi cancellare una chiave di registro fai esattamente lo stesso:
    	CD HKLM:\SOFTWARE
    	DEL PIPPO
Idem con i certificati. Un ipotetico provider Exchange o Domino o MDaemon 
o chissà cosa potrebbe fare lo stesso per cancellare una casella di 
posta. 
MS

Max_Adamo <massimiliano.adamo@N_OSPAMsun.com> wrote in
news:pan.2006.06.27.08.24.32.373718@N_OSPAMsun.com: 
Technet (che è una parte della documentazione) è su web a gratis.
Il resto è scaricabile.
Il punto è che il modello della documentazione di IBM è simile a quello MS 
con la differenza che i libri MS Press si pagano e i Redbook sono gratis. 
Sicuramente meglio IBM in tal senso ma non mi si può venire a dire che non 
c'è documentazione sui prodotti Microsoft. 
Invece di FDISK (un comando DOS e non Windows) cerca nell'help di un XP 
qualcosa di più significativo (come ad esempio Prncnfg.vbs o taskkill o 
netsh) e dimmi se non c'è documentazione.  
MS

THe_ZiPMaN wrote:
:: GdG wrote:
::: Beh, i contenuti di Technet sono disponibili gratuitamente su
::: internet.
::
:: Fino a qualche anno fa (ovvero fin quando mi occupavo di MS), non
:: tutti i contenuti della TN c'erano su Internet, e comunque la loro
:: fruibilità era nettamente diversa (in effetti nella TN su Internet
:: non si trova mai un cavolo).
Basta saper cercare.
:
:: Se così non fosse come sarebbero giustificabili i 500 euros?
Per il fatto che ci stanno altre cose oltre le KB?
Ma tanto è risaputo che Microsoft è un covo di gente di malaffare....

 Per il fatto che ci stanno altre cose oltre le KB?
Sì, fino al 2001 c'erano quei fantastici CD neri con le beta valide 120
giorni di tutti i principali programmi MS.
Oggi non è molto diverso.
http://www.microsoft.com/technet/abouttn/subscriptions/default.mspx
La parte interessante è e resta fondamentalmente la KB su DVD, che è
sempre stata utile.


 hai capito?
Credo che sbagli, in Rete c'č tutto. Per lo meno adesso, non so nel periodo 
a cui tu fai riferimento.
A supporto di ciň, il motore di ricerca della documentazione MSDN che 
accompagna Visual Studio 2005 offre l'opzione di ricercare non solo in 
locale ma soprattutto in Rete, dove la documentazione č piů aggiornata e 
ricca rispetto a quella presente nei soli DVD.
SALUTONI,
WindoM 

 cambiare le configurazioni.
E' possibile (anche se, a dire il vero, sarebbe comoda una versione
interattiva di regedit per console, tipo quella di ReactOS).
Tra parentesi, ho notato che e' possibile vedere anche i file aperti
localmente via console, cosa che fino ad oggi credevo possibile solo
tramite tool esterni.
Comunque, per terminarla, penso che il prompt dei comandi standard (si,
cmd.exe) piu' WSH colmano parecchie lacune a livello di
scripting/manutenzione del sistema via console. Quello che, secondo me,
manca veramente, e' qualcosa per la manipolazione del testo tipo grep,
cut, sed, awk (anche se, come detto, WSH sopperisce parecchio a questa
lacuna)
Enrico
P.S. e' bello vedere che windows e' una piacevole scoperta continua


http://www.microsoft.com/technet/abouttn/subscriptions/default.mspx
Oltre alla Beta, hai le service pack, gli aggiornamenti, slide e
webcast, due chiamate di supporto al PSS...
-- 
Rossano Orlandini

THe_ZiPMaN wrote:
:: GdG wrote:
::::: Fino a qualche anno fa (ovvero fin quando mi occupavo di MS), non
::::: tutti i contenuti della TN c'erano su Internet, e comunque la loro
::::: fruibilità era nettamente diversa (in effetti nella TN su Internet
::::: non si trova mai un cavolo).
:::
::: Basta saper cercare.
::
:: Quale parte di "non tutti i contenuti della TN c'erano su Internet"
:: non hai capito?
Quà occorre fondare il CICAZ.....
Saluti.

 semplice.
dsadd, ADSI
csvde, ldifde
anche  in windows si puņ automatizzare/scriptare tutto
basta semplicemente esserne capaci 

 basta semplicemente esserne capaci
Premetto che, come già è noto, sono un sysadmin windows abbastanza inetto,
però come cacchio fai a scriptare agevolmente in windows? coi .bat? coi
vbscript? con cmd.exe? con l'impossibilità di lavorare in remoto da linea
di comando?
fai tutto con software di terze parti, immagino?
Non so, chiedo...
-- 
Vide

Vide wrote:
:: Severo ha scritto:
::
::: anche in windows si può automatizzare/scriptare tutto
::: basta semplicemente esserne capaci
::
:: Premetto che, come già è noto, sono un sysadmin windows abbastanza
:: inetto, però come cacchio fai a scriptare agevolmente in windows?
:: coi .bat? coi vbscript? con cmd.exe? con l'impossibilità di lavorare
:: in remoto da linea di comando?
E chi l'ha detto che non ci sta la riga di comando da remoto?

 default in un Windows 2003. Corretto?
e magari, scava-scava, scropri che questo fantomatico software ha pure un
licenza che costa 300$ l'anno.... per aggiungere gli utenti via script.


Vide wrote:
:: Cioč, che poi per amministrarlo mi possa attaccare con MMC in remoto
:: e tutto quello che vuoi non lo nego certo, perň attualmente per lo
:: *scripting* mi pare nettamente inferiore (ma propro tanto) a una
:: qualunque distro Linux in generale. O a un BSD.
Nel resource kit (aggratis) ci sta RSH.
Con WSH dalla versione 5.6 puoi eseguire gli scritp che hai sulla tua 
macchina su una macchina remota.

Vide wrote:
:: Ma non mi interessa se è aggratis, è a parte! Cribbio, in Windows
:: Server c'è di default un web server e lasciano cose come una shell
:: decente fuori a parte?
Ma gli amministratori clicckete clacckete che se ne fanno di quella cosa?
E datti na regolata pure tu no?

 ah finalmente si comincia a vedere la famosa Monad....
Detto cosě da un veneto potrebbe anche essere capito male... e si che 
informatici e mona(d) non vaddo d'accordo a quel che dicono... :-P
Scusate le cazzata, ma non ho resistito
-- 
Saluti,
Muttley