¿Por qué el cd no es un progtwig?

Siempre me he preguntado por qué el cd no es un progtwig, pero nunca logramos encontrar la respuesta.

Alguien sabe por qué este es el caso?

El command cd modifica el "directory de trabajo actual", ¿verdad?

"directory de trabajo actual" es una propiedad que es única para cada process.

Entonces, si el cd fuera un progtwig, funcionaría así:

  1. cd foo
  2. el process de cd comienza
  3. el process de cd cambia el directory para el process de cd
  4. el process de cd sale
  5. su shell todavía tiene el mismo estado, incluido el directory de trabajo actual, que tenía antes de que usted comenzara.

cd además de ser un shell incorporado, es en realidad también un progtwig en sistemas operativos compatibles con POSIX. Deben proporcionar ejecutables independientes para los services regulares, como cd . Este es, por ejemplo, el caso de Solaris , AIX , HP-UX y OS X.

Obviamente, un cd incorporado sigue siendo obligatorio ya que su implementación externa no cambia el directory de shell actual. Sin embargo, este último aún puede ser útil. Aquí hay un ejemplo que muestra cómo POSIX visualiza cómo podría usarse este command de cd :

 find . -type d -exec cd {} \; 

En un sistema POSIX, este oneliner informará sobre un post de error para todos los directorys en los que no tiene permitido hacer cd . Sin embargo, en la mayoría de las distribuciones Gnu / Linux, falla con ese post de error:

 find: `cd': No such file or directory 

Y aquí está la respuesta a su pregunta, " ¿Por qué el cd no es un progtwig? " Por uno de los coautores originales de Unix. En una implementación muy temprana de Unix, el cd ( chdir deletreado en ese momento) era un progtwig externo. Simplemente dejó de funcionar inesperadamente después de que se implementó el fork por primera vez.

Citando a Dennis Ritchie :

En medio de nuestro júbilo, se descubrió que el command chdir (cambiar el directory actual) había dejado de funcionar. Hubo mucha lectura de código e introspección ansiosa acerca de cómo la adición de la horquilla podría haber roto la llamada chdir. Finalmente, la verdad amaneció: en el viejo sistema, el chdir era una order ordinaria; ajustó el directory actual del process (único) conectado al terminal. Bajo el nuevo sistema, el command chdir cambió correctamente el directory actual del process creado para ejecutarlo, ¡pero este process terminó de inmediato y no tuvo ningún efecto en su shell padre! Fue necesario hacer un command especial a chdir, ejecutado internamente dentro del caparazón. Resulta que varias funciones tipo command tienen la misma propiedad, por ejemplo, inicio de session.

Fuente: Dennis M. Ritchie, " La Evolución del Sistema de Tiempo Compartido de Unix ", AT & T Bell Laboratories Technical Journal 63 (6), Parte 2, octubre de 1984, pp.1577-93

La página de manual de chdir de Unix Version 1 (marzo de 1971) dice:

Debido a que se crea un nuevo process para ejecutar cada command, chdir sería ineficaz si se escribiera como un command normal. Por lo tanto, es reconocido y ejecutado por Shell.

De la introducción de Bash ( ¿Qué es un caparazón? ):

Las shells también proporcionan un pequeño set de commands incorporados (builtins) que implementan la funcionalidad imposible o incómoda de get a través de utilidades separadas. Por ejemplo, cd , break , continue y exec ) no pueden implementarse fuera del shell porque manipulan directamente el propio shell. La history , getopts , kill o pwd builtins, entre otros, podrían implementarse en utilidades separadas, pero son más convenientes para usar como commands integrados. Todos los shell builtins se describen en secciones posteriores.

Para April Fool's este año, escribí una versión independiente de cd .

Nadie entendió la broma. Suspiro.

Cualquiera que no esté seguro de que el cd debe estar integrado en el shell debe downloadlo, comstackrlo e intentarlo.

Lea su página man, también. 🙂

El command cd en shell no puede ser un process separado porque en Unix no hay un mecanismo para cambiar el directory de trabajo actual de un process diferente (ni siquiera el process principal).

Si cd fuera un process diferente, entonces tendría que cambiar el directory de trabajo actual de su principal (shell), que no es posible en Unix. En cambio, el cd es un command especial incorporado. El intérprete de commands llama a funciones como chdir() y fchdir() cambiando su propio directory de trabajo actual.

Nota: el kernel almacena el número de inodo del directory de trabajo actual para cada process. El process secundario henetworkinga su origen de su padre.

cd es un command integrado de shell. Tan fácil como es. El hombre cd lo dice todo. el command cd cambia el directory de trabajo para todos los intérpretes y (en un entorno de subprocesss) todos los subprocesss.

Creo que falta algo en la respuesta de las personas es que el directory actual es una variable de entorno que cada progtwig puede cambiar. Si usa el command 'exportar' para ver su list de variables de entorno actual, tendrá:

 declare -x PWD="/home/erfan" 

en tus resultados Por lo tanto, con el command 'cd' solo queremos modificar esta variable interna. Creo que si lo intentamos, podemos cambiar la variable PWD de cualquier pty en shell, por supuesto. Me gusta:

 cder #change current PTY $PWD variable 

Pero creo que no es necesario en casos normales. En otra palabra, tomamos ayuda de bash (o cualquier shell) para modificar su variable interna definida.