Questions tagged «file-descriptors»

如果我这样做（在类似Bourne的外壳中）： exec 3> file 4>&3 5> file 6>> file 由于3是dup()ed的4，所以文件描述符3和4 共享相同的打开文件描述（相同的属性，文件中的相同偏移量...）。虽然该过程的文件描述符5和6在不同的打开文件描述中（例如，它们各自在文件中都有自己的指针）。 现在，在lsof输出中，我们看到的是： zsh 21519 stephane 3w REG 254,2 0 10505865 /home/stephane/file zsh 21519 stephane 4w REG 254,2 0 10505865 /home/stephane/file zsh 21519 stephane 5w REG 254,2 0 10505865 /home/stephane/file zsh 21519 stephane 6w REG 254,2 0 10505865 /home/stephane/file 更好lsof +fg： …

17 file-descriptors 

根据bash手册页： 重定向运算符 [n]<&digit- 将文件描述符移动digit到文件描述符n，如果n未指定，则将标准输入（文件描述符0）移动 到文件描述符。digit复制到后关闭n。 将文件描述符“移动”到另一个文件描述符是什么意思？这种做法的典型情况是什么？

16 bash  io-redirection  file-descriptors 

我正在尝试使用文件描述符获取整个图片。假设我有process1，它最初具有这些文件描述符： _process1_ | | | 0 stdin | | 1 stdout | | 2 stderr | |__________| 然后我关闭文件描述符1： close(1); 文件描述符1转换（指向）内核的Open Files Table中的stdout FILE结构。 使用上面的代码，文件描述符1从进程表中删除，该表变为： _process1_ | | | 0 stdin | | 2 stderr | |__________| 但是内核中会发生什么呢？stdoutFILE结构是否被释放？如果stdout是一个特殊文件（监视器）并且可能被其他进程使用，那怎么可能？只是普通文件（例如.txt）的FILE结构怎么样？如果其他进程正在使用该文件怎么办？

16 linux  open-files  file-descriptors 

在他的关于网页的自管绝招，丹·伯恩斯坦解释了竞争条件select()和信号，提供一个解决办法，并得出结论认为， 当然，正确的事情是fork()返回文件描述符，而不是进程ID。 他的意思是-能够select()在子进程上处理其状态更改，而不必使用信号处理程序来通知那些状态更改，这是否有意义？

16 signals  file-descriptors  fork 

当您重定向包含exec重定向的命令列表时，此后exec> / dev / null似乎仍然没有被应用，例如： { exec >/dev/null; } >/dev/null; echo "Hi" 打印“ Hi”。 我的印象是，{}除非命令列表是管道的一部分，否则它不被视为子外壳，因此exec >/dev/null外壳在我看来仍应在当前的外壳环境中应用。 现在，如果将其更改为： { exec >/dev/null; } 2>/dev/null; echo "Hi" 没有预期的输出；对于以后的命令，文件描述符1仍指向/ dev / null。通过重新运行可以看到： { exec >/dev/null; } >/dev/null; echo "Hi" 没有任何输出。 我尝试制作脚本并对其进行分级，但是我仍然不确定此处到底发生了什么。 在此脚本的每一点上，STDOUT文件描述符发生了什么？ 编辑：添加我的strace输出： read(255, "#!/usr/bin/env bash\n{ exec 1>/de"..., 65) = 65 open("/dev/null", O_WRONLY|O_CREAT|O_TRUNC, 0666) …

15 bash  shell  command-line  io-redirection  file-descriptors 

我知道exec可以在当前shell上进行I / O重定向，但是我只会看到类似的用法： exec 6<&0 # Link file descriptor #6 with stdin. # Saves stdin. exec 6>&1 # Link file descriptor #6 with stdout. # Saves stdout. 据此，我了解<输入流，>输出流。那怎么exec 3<&1办？ PS：我从Bats源代码中找到了这个

14 bash  shell  io-redirection  file-descriptors  exec 

为什么ssh -t不等待后台作业完成？ 例： ssh user@example 'sleep 2 &' 这可以按预期工作，因为ssh在2秒后返回，而 ssh user@example -t 'sleep 2 &' 不等待sleep完成并立即返回。 谁能解释这背后的原因？有没有办法让ssh -t所有后台进程完成后再返回？ 我的用例是使用来启动一个脚本ssh -t，并且该脚本启动了一些后台作业，这些作业应在主脚本完成后仍然存在。随着ssh -t这是不可能的为止。

13 shell  ssh  process  background-process  file-descriptors 

我正在尝试使用文件描述符查找网络接口的速度。为此很容易ethX，只需致电即可cat /sys/class/net/eth0/speed。不幸的是，这种方法不适用于无线接口。当我打电话给/sys/class/net/wlan0/speed我时报错：参数无效。 那么，您知道/sys/class/net/eth0/speed无线接口的类似模拟吗？

13 linux  ubuntu  wifi  file-descriptors 

有没有办法关闭所有打开的文件描述符，而无需事先获得它们的明确列表？

13 bash  shell  file-descriptors 

我在不同的GNU / Linux安装上对此进行了测试： perl -e 'while(1){open($a{$b++}, "<" ,"/dev/null") or die $b;print " $b"}' 系统A和D 我遇到的第一个限制是1024。可以通过将其放入/etc/security/limits.conf来轻松提高它： * hard nofile 1048576 然后运行： ulimit -n 1048576 echo 99999999 | sudo tee /proc/sys/fs/file-max 现在测试进行到1048576。 但是，看来我无法将其提高到1048576以上。如果我将1048577放入limits.conf中，将被忽略。 是什么原因造成的？ 系统B 在系统BI上甚至无法达到1048576： echo 99999999 | sudo tee /proc/sys/fs/file-max /etc/security/limits.conf： * hard nofile 1048576 在这里我得到： $ ulimit -n 65537 …

13 linux  limit  file-descriptors  ulimit 

当连接到SSH与一台主机，通常主机和客户之间提供了三个“管道”，为stdin，stdout和stderr。 是否有一个命令行选项可为其他文件描述符（3以及向前）创建转发？ 例如，我想做 ssh --forwardfd=10:3 remotehost 'echo test >&3' 这会在本地打开的文件描述符10中打印“测试”。

12 ssh  pipe  file-descriptors 

我想让bash脚本在打开时将附加信息输出到大于或等于3的文件描述符（FD）。为了测试FD是否打开，我设计了以下技巧： if (printf '' 1>&3) 2>&-; then # File descriptor 3 is open else # File descriptor 3 is not open fi 这足以满足我的需求，但是我很好奇是否有一种惯用的方法来测试FD是否有效。我特别是约是否存在所述的映射感兴趣fcntl(1)系统调用到外壳命令，这将允许FD标志的检索（O_WRONLY和 O_RDWR测试的FD是否可写，和O_RDONLY和 O_RDWR测试的FD是否可读）。

12 bash  file-descriptors 

我想知道文件描述符和文件名之间有什么区别和关系。它们都用来访问文件吗？如果是，是否以同样的方式？ 例如/dev/fd/0，/dev/stdin和/proc/self/fd/0对所有链接/dev/pts/2。这是四个文件描述符还是文件名？

12 filenames  file-descriptors 

从Unix Power Tools，第3版：清空文件部分，而不是删除文件： 如果活动进程打开了文件（对于日志文件来说并不罕见），则删除该文件并创建一个新文件不会影响日志记录程序。这些消息只会继续转到不再链接的文件。清空文件不会破坏关联，因此清除文件不会影响日志记录程序。 （重点是我的） 我不明白为什么程序会继续记录到已删除的文件。是因为文件描述符条目没有从过程表中删除吗？

12 files  logs  open-files  file-descriptors 

如上所述这里，使用重定向open()写入到一个文件中。在外壳程序中创建了一个内部（？）文件描述符，然后在需要时使用它。 内部描述符是在脚本或Shell生命周期的整个过程中创建的吗？经过一段时间，多次操作等，它会被销毁吗？ 我的意思是特别是shell本身为其内置操作打开的文件的文件描述符。是否为每个操作创建了描述符并打开了文件？他们保留了多久？例： #!/bin/bash >>x echo something ...do many other things not related to the file x >>x echo something more 是否将第一个描述符实例保留到第二个操作？ 我在终端中使用的外壳呢？有时，我每天开放一次会议，甚至可能持续数周。它是否仍保留我使用Shell内置程序操作的所有文件的描述符？

11 bash  file-descriptors  memory-management