Qual è lo scopo della sospensione ritardata (Ctrl-Y) in Bash?

30

L'intera parte della pagina man di Bash che è applicabile dice solo:

Se il sistema operativo su cui è in esecuzione bash supporta il controllo dei lavori, bash contiene funzionalità per usarlo. Digitando il carattere di sospensione (in genere ^ Z, Control-Z) mentre è in esecuzione un processo, il processo viene interrotto e il controllo torna a bash. Digitando il carattere di sospensione ritardata (in genere ^ Y, Control-Y), il processo viene arrestato quando tenta di leggere l'input dal terminale e il controllo viene riportato alla bash. L'utente può quindi manipolare lo stato di questo lavoro, usando il bg comando per continuare in background, ilfgcomando per continuare in primo piano, o il comando kill per ucciderlo. A ^ Z ha effetto immediato e ha l'effetto collaterale aggiuntivo di scartare l'output in sospeso e il typeahead.

Non ho mai usato Ctrl- Y; Ne ho appena imparato. Ho fatto bene solo con Ctrl- Z(sospendi).

Sto cercando di immaginare cosa questa opzione è per . Quando sarebbe utile?

(Nota che questa funzione non esiste su tutte le varianti di Unix. È presente su Solaris e FreeBSD ma non su Linux. L'impostazione corrispondente è stty dsusp.)

Forse meno soggettivamente: c'è qualcosa che può essere realizzato con Ctrl- Yche non può essere realizzato altrettanto facilmente con Ctrl- Z?

— jolly
fonte

@Gilles, anche se FreeBSD sembra avere un stty dsusp, non sono riuscito a farlo inviare un SIGTSTP su ^ Y (l'ho fatto su Solaris). Hai?

— Stéphane Chazelas,

23

Dal manuale di 4BSD per csh :

A ^Zha effetto immediato ed è come un interrupt in quanto l'output in sospeso e l'input non letto vengono eliminati quando viene digitato. C'è un altro tasto speciale ^Yche non genera un segnale di STOP fino a quando un programma non tenta di leggerlo (2). Questo può essere utilmente digitato in anticipo quando hai preparato alcuni comandi per un lavoro che desideri interrompere dopo averli letti.

Pertanto, lo scopo è digitare più input mentre il primo viene elaborato e interrompere il lavoro dopo averli eseguiti.

— Random832
fonte

Questa descrizione è leggermente diversa dal manuale di bash. "... non genera un segnale di STOP fino a quando un programma tenta di leggere esso. " Sembra tutto in ingresso flusso fino alla ^Yverranno letti correttamente, e poi, quando il ^Yè colpito verrà interrotto il processo. Sto leggendo questo giusto?

— Wildcard il

@Wildcard nel mio test su Mac OS X, il processo viene interrotto prima che read () ritorni (ma dopo la chiamata a read () che avrebbe restituito Y viene eseguita), e dopo che viene ripreso riceve l'input da prima ^ Y . Penso che questo sia destinato a essere utilizzato, tuttavia, sarebbe utilizzato all'inizio di una riga, quindi il comportamento in questo caso non avrebbe importanza. Sospetto che nel codice effettivo sia sospeso quando ^ Y sarebbe stato copiato nel buffer di lettura del processo utente.

— Casuale 832,

Avevo ragione, nella funzione ttread del kernel originale BSD puoi vederlo e il moderno OSX

— Random832

Tuttavia, quando il processo viene ripreso, la chiamata avrà esito positivo e conterrà i dati digitati nel terminale in precedenza ^Y, anche se il processo è stato rinnegato e chiuso, prima che il processo venga ripreso. Destra? ( "... dopo che è stato ripreso riceve l'input da prima di ^ Y." Questo è quello che intendevo dire; di solito non mi occupo di codice C.) :)

— Wildcard

Sì. E ritorna senza una nuova riga alla fine, il che è insolito per una lettura in modalità canonica [simile a se avessi digitato del testo e poi premuto ^ D una volta] Sospetto che non abbiano pensato molto a questo caso, dal momento che è davvero pensato per essere digitato all'inizio di una riga.

— Casuale 832

11

Supponiamo che ci sia un loop che legge input ed esecuzione. Può essere utile lasciare che l'attività completi l'istruzione corrente che calcola, senza interromperla prima che torni alla riga di comando per una nuova. Quindi, quindi, per terminare un ciclo. Questo termina il ciclo con garbo e ne impedisce l'esecuzione se readè soggetto a una limitazione di timeout.

— Tomasz
fonte

Ma se sta andando a cercare di leggere l'input dal terminale in ogni caso, sarà fermarsi in quel punto (e aspettare il vostro input), ed è possibile ^Zche poi .

— Carattere jolly

Sì. Vedi aggiornamento

— Tomasz,

Controlla ancora uno. @Wildcard

— Tomasz

1

Ma se ha un timeout, non finirebbe semplicemente con grazia se non facessi nulla di speciale?

— Daniel Wagner,

1

Potrebbe. Ma potrebbe anche andare avanti e fare un lavoro predefinito.

— Tomasz,

4

Mi viene in mente uno scenario in cui potrebbe essere utile, ma è una specie di caso inventato.

Supponiamo che tu stia eseguendo il debug di uno script che sta scrivendo file temporanei che desideri analizzare prima che vengano eliminati come parte di una routine di pulizia.

È possibile aggiungere un punto read foodopo la scrittura dei file (ma prima della pulizia), eseguire lo script e premere Ctrl- Ymentre vengono generati. Verrai quindi reindirizzato a un prompt con lo script sospeso in background per fare tutto ciò che devi fare e quindi fgconsentire il completamento dello script.

— DopeGhoti
fonte

1

Sembra improbabile, perché lo script attenderà comunque l'input. Quindi potresti facilmente cercarlo per richiedere un input e quindi sospenderlo con ^Z. In altre parole: dopo aver digitato fgsi dovrà dare allo script qualche input in ogni caso prima che possa continuare. Da qui la mia domanda; Continuo a non capire il punto ^Y. (Grazie per aver risposto, però!) :)

— Carattere jolly

2

L'unico scenario che mi viene in mente (e anche se non lo trovo molto convincente) è se si desidera utilizzare un tipo di anticipo per un comando shell. Supponiamo che sia in esecuzione un comando che leggerà l'input qualche tempo in futuro. Quindi è possibile ^ Y esso, quindi digitare immediatamente il comando di shell successivo che si desidera eseguire quando il comando in esecuzione viene sospeso. Non credo di averlo mai usato davvero in diversi decenni di utilizzo di BSD Unix.

— Olaf Seibert
fonte