首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

有人可以在Solaris中解释这个'dirent'结构的定义吗?

当然可以。dirent 是一个结构体,它在 Solaris 中定义在 <dirent.h> 头文件中。它用于表示目录条目,即目录中的单个文件或子目录。dirent 结构体通常包含以下成员:

  • ino_t d_ino:这是一个 inode 号,它是一个唯一的整数,用于标识文件系统中的每个文件和目录。
  • off_t d_off:这是一个偏移量,表示目录中该条目的位置。
  • unsigned short d_reclen:这是一个无符号短整数,表示该目录条目的长度。
  • char d_name[]:这是一个字符数组,包含文件或目录的名称。

在 Solaris 中,可以使用 readdir() 函数来读取目录条目。这个函数返回一个指向 dirent 结构体的指针,可以用来访问目录中的每个条目。

以下是一个简单的示例,展示了如何使用 readdir() 函数遍历目录中的所有条目:

代码语言:c
复制
#include <dirent.h>
#include<stdio.h>

int main(void) {
    DIR *dir;
    struct dirent *entry;

    dir = opendir(".");
    if (dir == NULL) {
        perror("Failed to open directory");
        return 1;
    }

    while ((entry = readdir(dir)) != NULL) {
        printf("%s\n", entry->d_name);
    }

    closedir(dir);
    return 0;
}

这个示例打开当前目录,并使用 readdir() 函数读取每个目录条目。然后,它将每个条目的名称打印到控制台上。最后,它关闭目录并返回。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

  • ZFS是什么?使用ZFS的理由及特性介绍

    Z 文件系统(Z File System)(ZFS)是由 Matthew Ahrens 和 Jeff Bonwick 在 2001 年开发的。ZFS 是作为 太阳微系统(Sun MicroSystem) 公司的 OpenSolaris 的下一代文件系统而设计的。在 2008 年,ZFS 被移植到了 FreeBSD 。同一年,一个移植 ZFS 到 Linux 的项目也启动了。然而,由于 ZFS 是 通用开发和发布许可证 (Common Development and Distribution License)(CDDL)许可的,它和 GNU 通用公共许可证 不兼容,因此不能将它迁移到 Linux 内核中。为了解决这个问题,绝大多数 Linux 发行版提供了一些方法来安装 ZFS。 在甲骨文公司收购太阳微系统公司之后不久,OpenSolaris 就闭源了,这使得 ZFS 的之后的开发也变成闭源的了。许多 ZFS 开发者对这件事情非常不满。 三分之二的 ZFS 核心开发者 ,包括 Ahrens 和 Bonwick,因为这个决定而离开了甲骨文公司。他们加入了其它公司,并于 2013 年 9 月创立了 OpenZFS 这一项目。该项目引领着 ZFS 的开源开发。 让我们回到上面提到的许可证问题上。既然 OpenZFS 项目已经和 Oracle 公司分离开了,有人可能好奇他们为什么不使用和 GPL 兼容的许可证,这样就可以把它加入到 Linux 内核中了。根据 OpenZFS 官网 的介绍,更改许可证需要联系所有为当前 OpenZFS 实现贡献过代码的人(包括初始的公共 ZFS 代码以及 OpenSolaris 代码),并得到他们的许可才行。这几乎是不可能的(因为一些贡献者可能已经去世了或者很难找到),因此他们决定保留原来的许可证。

    02

    硬件兼容的UNIX起源和谱系(11k字)

    科学Sciences导读:纵观计算机历史,操作系统与计算机硬件的发展息息相关。本文从操作系统演进的五个阶段(9k字)、早期操作系统的发展阶段(10k字)、硬件兼容的UNIX起源和谱系(11k字)、可视化操作系统成主流(29k字)、操作系统功能和技术简介(4k字)等五个方面,介绍计算机操作系统的演进、谱系和产品发展史。计算机发展过程中,出现过许多操作系统:DOS、MacOS、Windows、Unix、Linux、Free BSD等。关键词:计算机,操作系统,OS,Multics,Unics,Unix,Minux,Linux,Xenix、OS/2、Dos,Windwows,iOS,Android,演进,谱系。赞赏支持科普作者后,公号输入栏发送“操作系统史”获取本PDF资料,下载学习科技知识。

    03

    Unix编程/应用问答中文版 ---6./etc/system可调资源限制

    本文出自:[url]http://www.nsfocus.com[/url] 维护:小四 6. /etc/system可调资源限制 6.1 Solaris下如何限制每个用户可拥有的最大进程数 6.2 如何配置系统使之支持更多的伪终端 6.3 如何增加每个进程可打开文件句柄数 6.4 6.5 做了setuid()这类调用的程序如何产生core dump 6.6 消息队列调整 -------------------------------------------------------------------------- 6. /etc/system可调资源限制 6.1 Solaris下如何限制每个用户可拥有的最大进程数 A: Casper Dik 在/etc/system设置 set maxuprc = Q: maxusers参数究竟影响了什么 A: Casper Dik 下面以/etc/system语法格式举例说明: * set maxusers = <以MB为单位计的可用物理内存数量> * 系统所允许的最大进程数,通常最多30000 set max_nprocs = 10 + 16 * maxusers * 每个用户可以拥有的最大进程数(为超级用户保留5个) set maxuprc = max_nprocs - 5; # sysdef | sed -n '/System Configuration/,$p' 6.2 如何配置系统使之支持更多的伪终端 A: Argoth 不要试图通过'/usr/bin/adb -k'到达目的。 a. 如果Solaris版本小于7,修改/etc/system,增加如下行 set pt_cnt= 执行/usr/sbin/reboot -- -r,或者Stop-A,执行boot -r b. 对于Solaris 8,支持的伪终端数目根据需要动态改变,系统依然有一个内部限制, 但是这个值非常大。如果"pt_cnt"变量小于这个内部限制,将被忽略。一般情况 下,不再需要指定"pt_cnt"变量。但还是有某些罕见的情形,需要设置"pt_cnt" 变量大于内部限制。 6.3 如何增加每个进程可打开文件句柄数 A: Casper Dik 从Solaris 2.4开始,可以通过修改/etc/system实现 * set hard limit on file descriptors set rlim_fd_max = 4096 * set soft limit on file descriptors set rlim_fd_cur = 1024 软限制超过256时,某些应用程序会出问题,尤其BCP程序。软限制超过1024时,那些 使用select()的应用程序可能会出问题。Solaris 7之前,select()使用的文件句柄 数不能超过1024。Solaris 2.6的RPC代码被重写过了,使用poll()代替select(),可 以使用超过1024的文件句柄。Solaris 2.6之前,如果软限制超过1024,所有RPC服务 很可能崩溃。 Solaris 7下select()可以使用最多达65536的文件句柄,64-bit应用程序缺省情况如 此。如果是32-bit应用程序,需要指定给FD_SETSIZE一个更大的值,重新编译。 如果程序使用标准输入/输出(stdio),或者调用那些使用stdio的库函数,当打开的 文件超过256时,程序可能会出问题,这个限制是stdio的限制。当程序需要大量文件 句柄时,应该想办法保留一些小数字的文件句柄,让stdio使用它们。 Solaris 7下64-bit应用程序不再受这个stdio限制的影响。如果你的确需要超过256 个FILE *,而又不能使用Solaris 7,或者需要运行32-bit代码,考虑使用来自AT&T 的SFIO([url]http://www.research.att.com/sw/tools/sfio/[/url])。 A: [email]qaz@smth.org[/email] 检查当前设置 # ulimit -H -n 1024 # ulimit -S -n 64 # 对于Solaris,建议修改/etc/system后重启 * set hard limit on file descriptors set rlim_fd_max=0x8000 * set soft limit on file descriptors set rlim_fd_cur=0x8000 然后 ulimit -S -n 8192 对于Linux echo 65536 > /proc/sys/fs/file-max 然后 ulimit -S -n 8192 对于FreeBSD 编辑/etc

    03

    JDK 15 要来了,新特性尝鲜。

    Java Development Kit 15是甲骨文公司发布 Java SE(标准版)的最新版本,它在6月11日进入缓降阶段,系列功能现在被冻结。JDK 15的亮点包括文本块、隐藏类、外部内存访问API以及密封类和记录的预览。 Java升级的下一个阶段是另一个缓降阶段,从现在起到8月20日有两个可选版本。预计9月15日正式上市。JDK15紧随3月17日发布的JDK14。甲骨文公司遵循标准Java六个月的发布计划,新版本每年发布两次。 第二个孵化器外部内存访问API,它可以使Java程序安全、高效地访问Java堆栈之外的外部内存。API应该能够对各种类型的外部内存进行操作,例如本机内存、持久内存和托管堆。许多Java程序访问外存,如Ignite和MapDB。API将有助于避免垃圾收集相关的成本和不可预测性,跨进程共享内存,并通过将文件映射到内存来序列化和反序列化内存内容。javaAPI目前还没有为访问外存提供令人满意的解决方案。但有了新的提议,即API不应该破坏JVM的安全性。这个功能在jdk14中经历了早期的孵化阶段,在jdk15中进行了改进。 密封类的预览。与接口一起,密封类限制了那些可以扩展或执行的其它类或接口。此特性的目标包括允许类或接口的作者控制由哪些代码负责实现它,并提供比访问修饰符更具声明性的方式来限制超类的使用,还有通过支持对模式的详尽分析来支持模式匹配的未来方向。 删除对Solaris/SPARC、Solaris/x64和Linux/SPARC端口的源代码和构建支持,而在JDK 14中不赞成删除这些端口,但可在将来的版本中删除它们。许多正在开发的项目和功能(如Valhalla、Loom和Panama)需要进行重大更改以适应CPU架构和操作系统特定代码。放弃对Solaris和SPARC端口的支持将使OpenJDK社区的贡献者加快开发新特性,从而推动平台向前发展。近年来,Solaris和SPARC都被Linux操作系统和Intel处理器所取代。 记录作为不可变数据的透明载体的类,在jdk14中作为早期预览发布之后,将被包含在jdk15的第二个预览版本中。该计划的目标包括设计一个面向对象构造来表达一个简单的值聚合。以协助程序员专注于不可变数据的建模,而非扩展性行为。自动实现数据驱动的方法,如equals和assessors,并保留Java中长期存在的原则,如名义类型和迁移兼容性。记录可以看作是名义元组。 基于爱德华曲线数字签名算法(EdDSA)的密码签名。EdDSA是一种现代的椭圆曲线方案,对比JDK中现有的签名方案更具有优势。EdDSA将仅在SunEC提供程序中执行。与其他签名方案相比,EdDSA具有更高的安全性和性能,因此受到人们的青睐;加密库中已经支持EdDSA,如OpenSSL和BoringSSL。 通过替换java.net.datagram.Socket和java.net.MulticastSocket APIs的实现以更简单和更现代的方式重新实现以前的DatagramSocket API。且易于调试和维护使用项目中当前正在探索的虚拟线程。新计划是JDK增强建议353的后续,该提议重新实现了遗留的Socket API。当前java.net.datagram.Socket和java.net.MulticastSocket的实现可以回溯到jdk1.0,那时IPv6还在开发中。因此,当前的MulticastSocket执行试图以难以维护的方式调节IPv4和IPv6。 默认情况下禁用偏向锁定并弃用所有相关的命令行选项。其目标是确定是否需要继续支持高代价维护,及偏向锁的遗留同步优化,该优化用于热点虚拟机,以减少竞争性锁定的开销。尽管某些Java应用程序可能会在禁用偏向锁定的情况下出现性能的回归,但是偏向锁的性能增益通常不如以前那么明显。instanceof匹配第二个预览模式,紧随JDK 14中之前的预览。模式匹配允许程序中的通用逻辑,主要是从对象中有条件地提取组件,以更简洁地表达。Haskell和C等语言因其简洁和安全而采用了模式匹配。 隐藏类,即不能被其他类字节码直接使用的类,倾向于借助框架使用,框架会在运行时生成类并通过反射间接使用它们。隐藏类可被定义为访问控制嵌套的成员,并且可以独立于其他类进行卸载。这项提议将提高JVM上所有语言的效率,方法是使用标准API定义不可发现且生命周期有限的隐藏类。

    02

    c++ 跨平台线程同步对象那些事儿——基于 ace

    ACE (Adaptive Communication Environment) 是早年间很火的一个 c++ 开源通讯框架,当时 c++ 的库比较少,以至于谈 c++ 网络通讯就绕不开 ACE,随着后来 boost::asio / libevent / libev … 等专门解决通讯框架的库像雨后春笋一样冒出来,ACE 就渐渐式微了。特别是它虽然号称是通讯框架,实则把各个平台的基础设施都封装了一个遍,导致想用其中一个部分,也牵一发而动全身的引入了一堆其它的不相关的部分,虽然用起来很爽,但是耦合度太强,学习曲线过于陡峭,以至于坊间流传一种说法:ACE 适合学习,不适合快速上手做项目。所以后来也就慢慢淡出了人们的视线,不过对于一个真的把它拿来学习的人来说,它的一些设计思想还是不错的,今天就以线程同步对象为例,说一下“史上最全”的 ACE 是怎么封装的,感兴趣的同学可以和标准库、boost 或任意什么跨平台库做个对比,看看它是否当得起这个称呼。

    01

    Emulex LightPulse FC9002L光纤卡安装日志

    # tar xvf solaris-6.01c-1a.tar x EmlxApps300a8-Solaris.tar, 6850560 bytes, 13380 tape blocks x lpfc-6.01c-sparc.tar, 1848832 bytes, 3611 tape blocks x readme.first.txt, 953 bytes, 2 tape blocks # ls EmlxApps300a8-Solaris.tar  readme.first.txt           ssh-UdjGS369 lpfc-6.01c-sparc.tar       solaris-6.01c-1a.tar # tar xvf lpfc-6.01c-sparc.tar x lpfc.1, 0 bytes, 0 tape blocks x lpfc.1/pkgmap, 1814 bytes, 4 tape blocks x lpfc.1/pkginfo, 276 bytes, 1 tape blocks x lpfc.1/install, 0 bytes, 0 tape blocks x lpfc.1/install/copyright, 480 bytes, 1 tape blocks x lpfc.1/install/postinstall, 9336 bytes, 19 tape blocks x lpfc.1/install/postremove, 2848 bytes, 6 tape blocks x lpfc.1/install/preremove, 1620 bytes, 4 tape blocks x lpfc.1/install/request, 2378 bytes, 5 tape blocks x lpfc.1/install/space, 23 bytes, 1 tape blocks x lpfc.1/reloc, 0 bytes, 0 tape blocks x lpfc.1/reloc/etc, 0 bytes, 0 tape blocks x lpfc.1/reloc/etc/system, 0 bytes, 0 tape blocks x lpfc.1/reloc/kernel, 0 bytes, 0 tape blocks x lpfc.1/reloc/kernel/drv, 0 bytes, 0 tape blocks x lpfc.1/reloc/kernel/drv/lpfc, 592692 bytes, 1158 tape blocks x lpfc.1/reloc/kernel/drv/lpfc.conf, 10863 bytes, 22 tape blocks x lpfc.1/reloc/kernel/drv/sd.conf, 1185 bytes, 3 tape blocks x lpfc.1/reloc/kernel/drv/sparcv9, 0 bytes, 0 tape blocks x lpfc.1/reloc/kernel/drv/sparcv9/lpfc, 719064 bytes, 1405 tape blocks x lpfc.1/reloc/usr, 0 bytes, 0 tape blocks x lpfc.1/reloc/usr/include, 0 bytes, 0 tape blocks x lpfc.1/reloc/usr/include/fcdiag.h, 18051 bytes, 36 tape blocks x lpfc.1/reloc/usr/lib, 0 bytes, 0 tape blocks x lpfc.1/reloc/usr/lib/libdfc.a, 43820 bytes, 86 tape blocks x lpfc.1/reloc/usr/lib/libdfc.so, 42000 bytes, 83 tape blocks x lpfc.1/reloc/usr/lib/sparcv9, 0 bytes, 0 tape blocks x lpfc.1/reloc/usr/lib/sparcv9/libdfc.a, 47936 bytes, 94 tape blocks x lpfc.1/reloc/usr/lib/sparcv9/libdfc.so, 51248 bytes, 101 tape blocks x lpfc.1/reloc/usr/sbin, 0 bytes, 0 tape blocks x lpfc.1/reloc/usr/sbin/lpfc, 0 bytes, 0 tape blocks x lpfc.1/reloc/usr/sbin/lpfc/convert_path_lpfc, 2257

    02
    领券