-
【Linux从入门到精通五】️ Linux命令行工具：深入探索cp、mv、rm、which、find、grep、wc、管道符、重定向符和vi编辑器
🛠️ Linux命令行工具：深入探索cp、mv、rm、which、find、grep、wc、管道符、重定向符和vi编辑器 在前一篇文章中，我们系统地介绍了Linux中的基础命令和概念，包括如何使用cd、pwd导航目录，以及mkdir、touch、cat等命令进行文件操作。本文将继续深入探讨Linux命令行工具，重点介绍cp、mv、rm、which、find、grep、wc命令，以及管道符、重定向符和vi编辑器的使用。这些工具和命令是Linux系统中不可或缺的一部分，掌握它们将极大地提高你的工作效率。 一、cp命令：复制文件和目录 cp命令用于复制文件或目录。它非常实用，可以在不同的目录之间复制文件，或者在复制的同时重命名文件。 1. 复制文件 复制单个文件非常简单： cp source.txt destination.txt 这将把source.txt复制到destination.txt。如果destination.txt已经存在，它会被覆盖。 2. 复制目录 要复制整个目录及其内容，可以使用-r（或-R）选项： cp -r sourcedir destinationdir 这将递归地复制sourcedir目录下的所有文件和子目录到destinationdir。 3. 保留文件属性 使用-p选项可以保留原文件的修改时间、访问时间和文件权限： cp -p source.txt destination.txt 二、mv命令：移动或重命名文件 mv命令不仅可以移动文件和目录，还可以用于重命名。 1. 移动文件 将文件从一个目录移动到另一个目录： mv source.txt /path/to/destination 如果目标路径是当前目录，可以直接使用： mv source.txt destination.txt 这将把source.txt移动到当前目录，并重命名为destination.txt。 2. 重命名文件 mv oldname.txt newname.txt 这将把oldname.txt重命名为newname.txt。 三、rm命令：删除文件和目录 rm命令用于删除文件和目录。使用时需谨慎，因为删除操作不可逆。 1. 删除文件 删除单个文件： rm file.txt 2. 递归删除目录 要删除非空目录，需要使用-r（或-R）……
SE_Wang 2024-12-26
6 0 0 -
中间件？C/S、B/S、中间件浅易讲解
随着技术系统的规模发展得足够复杂，导致了开发团队无法亲力亲为参与每个技术系统的全部建设，如果每次承接同类业务开发都从零开始对接，那么将大大增加研发成本。 这就导致了社会分工，有人把工程开发中基础的、底层的、共用的服务和逻辑包装成中间件，你只管使用就够了。简单理解：中间件就是将具体业务和底层逻辑解耦的组件。 给个比喻：中间件，就是所谓的中介，毕竟业务繁杂到一定程度后，干什么都需要中介。 让我们坐好板凳，回忆一下那些没有中间件的那些日子，除了最简单的不需要任何服务的单机版程序，一种较为朴实的技术系统设计架构叫做C/S架构。 一、C/S架构（客户端/服务器架构） C/S架构，即Client客户端/Server服务器架构，是一种分布式应用模式，最简单的系统功能分为两层：客户端和服务器端。 如下图，最简单的技术系统分为两层结构，在实际部署中就是一台服务器和一台或者若干台终端。终端就是客户端，需要安装客户端程序（比如.exe、.apk等应用程序），服务器上安装数据库系统，提供数据库存储服务。这种架构叫做两层结构。客户端负责用户界面和业务逻辑，服务器端负责数据存储和处理。 多客户端的话，C/S架构需要在每个客户端安装专用的软件。 当业务发展得稍微复杂了，客户端上的业务逻辑很复杂，我们为了让客户端瘦下来（不瘦下来的话，软件开发人员无法合理分工高效开发，另外对客户端配置要求也越来越高），这个时候，我们增加了一个应用服务中间层，我们在这台服务器上实现了应用服务。这就形成了三层结构。如上图所示。三层结构通常是指将整个业务应用划分为：表现层（客户端呈现）、业务逻辑层（应用服务关联）、数据访问层（数据库服务关联）。 三层结构在应用服务这个中间层慢慢发展，慢慢催生形成了一些中间件开发框架，也在某种意义上推动了C/S向……
SE_YT 2024-12-26
42 0 0 -
【Linux】文件IO–read/write/缓冲区
read/write函数 read函数： 函数描述: 从打开的设备或文件中读取数据 函数原型：ssize_t read(int fd, void *buf, size_t count); 函数参数: fd: 文件描述符 buf: 读取的数据保存在缓冲区buf中 count: buf缓冲区存放的最大字节数 函数返回值: >0：读取到的字节数 =0：文件读取完毕 -1： 出错，并设置errno write函数： 函数描述: 向打开的设备或文件中写数据 函数原型: ssize_t write(int fd, const void *buf, size_t count); 函数参数： fd：文件描述符 buf：缓冲区，要写入文件或设备的数据 count：buf中数据的长度 函数返回值: 成功：返回写入的字节数 错误：返回-1并设置errno 用法示例： ①read读取示例： int fd = open("./a.txt", O_RDONLY); char buf[1024]; int ret = read(fd, buf, sizeof(buf)); buf[ret] = '\0'; //字符串末尾添加结束标志 printf("buf = %s\n", buf); close(fd); ②在文件末尾写入： int fd = open("./a.txt", O_RDWR); //如果只读，write返回-1 char buf[1024]; int read_count = read(fd, buf, sizeof(buf)); // lseek(fd, 0, SEEK_SET); int write_count = write(fd, buf, read_count); printf("write_count = %d\n", write_count); ③覆盖原文件写入： int fd = open("./a.txt", O_RDWR); int fd2 = open("./b.txt", O_RDWR); //如果追加写入加上 O_APPEND char buf[1024]; int read_count = read(fd, buf, sizeof(buf)); int write_count = write(fd2, buf, read_count); printf("write_count = %d\n", write_count); 实现cp命令： #include<stdio.h> #include<stdlib.h> #include<string.h> #include<unistd.h> #include<fcntl.h> void copy(const char *from,char *to) { int fd; char buf[1024]; memset(buf,'\0',sizeof(buf)); fd=open(f……
11 0 0 -
Linux笔记—进程：进程地址空间
1. 地址空间 程序地址空间是指程序在执行期间可以访问的内存范围。它由操作系统为每个进程分配，以确保进程之间不会相互干扰。地址空间包含了程序所需的所有内存区域，包括代码、已初始化和未初始化的数据、堆（heap）、栈（stack）等。 2. 虚拟地址 什么是虚拟地址呢？我们在Linux笔记---进程：初识进程-CSDN博客中谈到过虚拟地址这一概念，现在再次回顾一下当时遇到的问题： #include <stdio.h> // fork函数包含在下面两个头文件中 #include <sys/types.h> #include <unistd.h> int main() { printf("我是一个进程，我的pid=%d，我即将创建子进程...\n", getpid()); int id = fork(); if(id == 0) { printf("我是一个子进程，我的pid=%d，我父进程的pid=%d，我得到的id=%d，&id=%p\n", getpid(), getppid(), id, &id); } else { printf("我是一个父进程，我的pid=%d，我子进程的pid=%d，我得到的id=%d，&id=%p\n", getpid(), id, id, &id); } return 0; } AI助手 由于fork函数返回值不同，对id写入的内容不同，导致id发生了写时拷贝，可以看到父子进程的id值确实是不同的。但问题是，二者的地址竟然是完全相同的？ 当时我们说，这是因为这里的地址其实是虚拟地址，其物理地址可能指向不同的空间。 我们先思考一个问题，在同一次程序运行的过程中，同一个变量的地址会发生变化吗？当然不会。 既然子进程继承了父进程的数据，那么出现这样的结果似乎完全是在意料之中的，但问题是，这是如何做到的呢？ 2.1 虚拟地址空间 实际上，每个进程都会有一个属于自己的虚拟地址空间，我们在程序中看到的、使用的，全部都是虚拟地址。虚拟地址空间中的地址会通过页表映射到物理地址空间。 这使得每个程序都认为自己能够使用整个内存空间。 程序地址空间通过虚拟内存和地址映射技术实现……
7 0 0 -
已解决centos7 yum报错：cannot find a valid baseurl for repo:base/7/x86_64的解决方案
报错说明 出现cannot find a valid baseurl for repo:base/7/x86_64错误通常是由于YUM仓库源无法找到或无法访问，导致YUM无法正常工作。这种情况常见于CentOS 7系统。解决这个问题需要检查几个方面，如网络连接、DNS设置和YUM仓库源配置。以下是详细的排查解决方法。 方法一：检查网络连接 首先，确保你的系统可以连接到互联网。这很重要，因为YUM需要访问远程仓库来下载软件包。 检查网络连接 可以通过以下命令检查系统是否能访问外部网站： ping -c 4 google.com AI助手 如果不能ping通，可能是网络配置问题。你需要确保网络连接正常，可能需要重新启动网络服务： sudo systemctl restart network AI助手 方法二：检查DNS设置 如果你的网络连接正常但依然不能访问仓库，可能是DNS问题。 更新DNS配置 编辑/etc/resolv.conf文件，确保其中包含有效的DNS服务器，例如Google的公共DNS： sudo nano /etc/resolv.conf AI助手 添加以下行： nameserver 8.8.8.8 nameserver 8.8.4.4 AI助手 保存文件并退出。 检查是否能解析域名 再次检查系统是否能解析域名： ping -c 4 google.com AI助手 方法三：检查YUM仓库配置 如果网络连接和DNS设置都正常，可能是YUM仓库配置有问题，需要检查并更新YUM仓库源。 更新YUM仓库源 备份现有的YUM配置文件： sudo cp -r /etc/yum.repos.d /etc/yum.repos.d.backup AI助手 编辑或替换仓库配置文件 检查/etc/yum.repos.d/CentOS-Base.repo文件。确保baseurl和gpgcheck配置正确。你可以手动编辑这个文件，或者更换为可靠的YUM仓库源。 示例：使用官方CentOS镜像配置 sudo nano /etc/yum.repos.d/CentOS-Base.repo AI助手 将内容替换为以下内容： [base] name=CentOS-$releasever - Base baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ gpgcheck=1 gpgkey=http://mi……
18 0 0 -
超清晰的DNS入门指南，看这篇就够了
01 DNS 是什么？ DNS是域名系统(DomainNameSystem)的缩写，它是由解析器和域名服务器组成的。 域名服务器是指保存有该网络中所有主机的域名和对应IP地址，并 具有将域名转换为IP地址功能的服务器。其中域名必须对应一个IP地址，而 IP地址不一定有域名。 域名系统采用类似目录树的等级结构。域名服务器为客户机 / 服务器模式中的服务器方，它主要有两种形式：主服务器和转发服务器。 将域名映射为IP 地址的过程就称为 “域名解析”。在 Internet上域名与IP地址之间是一对一（或者多对一）的，域名虽然便于人们记忆，但机器之间只能互相认识 IP 地址，它们之间的转换工作称为域名解析，域名解析需要由专门的域名 解析服务器来完成，DNS就是进行域名解析的服务器。 DNS 命名用于Internet 等 TCP/IP网络中，通过用户友好的名称查找计算机和服务。 当用户在应用程序中输入DNS名称时，DNS服务可以将此名称解析为与之相关的其他信息，如IP地址。因为，你在上网时输入的网址，是通过域名解析系统解析找到了相对应的IP地址，这样才能上网。其实，域名的最终指向是IP 。 举例来说，如果你要访问域名http://math.stackexchange.com，首先要通过DNS查出它的IP地址是151.101.129.69。 02 查询过程 虽然只需要返回一个IP地址，但是DNS的查询过程非常复杂，分成多个步骤。 工具软件dig可以显示整个查询过程。 $ dig math.stackexchange.com 上面的命令会输出六段信息。 第一段是查询参数和统计。 第二段是查询内容。 上面结果表示，查询域名http://math.stackexchange.com的A记录，A是address的缩写。 第三段是DNS服务器的答复。 上面结果显示，http://math.stackexchange.com有四个A记录，即四个IP地址。600是TTL值（Time to live 的缩写），表示缓存时间，即600秒之内不用重新查询。 第四段显示http://stackexcha……
SE_YJ 2024-12-23
7 0 0 -
【Linux】线程ID与互斥、同步(锁、条件变量)
线程ID及进程地址空间布局 运行代码，这个很大的数字就是线程id。 通过 ps -aL 指令，看到LWP跟线程id是不一样的。 给用户提供的线程的id，不是内核中的lwp，而是pthread库维护的一个唯一值。 我们把上面的数字转换成十六进制，可以看出这是一个地址 理解库 动态库被运行时加载，动态库没被加载前在磁盘中。 pthread库本质是一个文件。 我们刚刚写的可执行程序，它也是个文件，所以他也在磁盘中。可执行程序内部用线程库来创建多线程。 程序运行时，会变成一个进程，加载到内存中，内存中就有该进程的代码和数据。创建线程时，要先把库加载到内存中，然后再映射到该进程的地址空间才能用。映射要映射到堆栈之间的共享区。如果有多个多线程进程，它只需要把共享区的代码，经过页表映射到已经加载到内存的库，此时多个进程就可以使用同一个库里的方法来创建线程。 Linux只维护轻量级进程，linux中的pcb里与执行流相关的属性都是轻量级进程的属性，所有的属性都是围绕lwp展开的。我们在用户层的概念是线程，要的是线程的id，与线程相关的内容在Linux中是没有的，它没有维护。所以这部分属性由库来进行维护。 为了更好的管理线程，创建线程时，库会为我们的每一个线程申请一个内存块(描述线程的相关结构体字段属性)。 未来要找一个线程的所有属性，只要找到线程控制块的地址即可。所以pthread_t id就是一个地址。 pthread_t类型的线程ID，本质就是线程属性集合的起始虚拟地址 ---- 在pthread库中维护。 由上图可得，一个全局变量，本身就是被所有线程共享的。 如果我们想让两个线程各自私有一份变量，g++有一个编译选项 __thread 用__thread修饰这个全局变量即可。运行后，主线程和新线程gval的地址也不一样了。这种情况叫线程的局部存储，原始代码里只看到一个gval，但是他们用的是各自的gval。 这种情况只在Linux……
11 0 0 -
无监控，不运维！这份监控建议总结太赞了
01 常见的运维监控工具 现在运维监控工具非常多，哪个好，哪个不好，哪个适合你，哪个不适合你，其实只有你了解了他们的特性后，才知道，所以从这里开始讲起。 01 Cacti Cacti是一套基于PHP，MySQL，SNMP及RRDTool开发的网络流量监测图形分析工具。 简单的说Cacti就是一个PHP程序。它通过使用SNMP协议获取远端网络设备和相关信息（其实就是使用Net-SNMP 软件包的snmpget 和snmpwalk 命令获取）并通过RRDTOOL工具绘图，通过PHP程序展现出来。我们使用它可以展现出监控对象一段时间内的状态或者性能趋势图。 cacti是很老的一款监控工具了，其实说它是一款流量监控工具更合适，对流量监控比较精准，但缺点很多，出图不好看，不支持分布式，也没有告警功能，所以使用的人会越来越少。 02 Nagios Nagios是一款开源的免费网络监视工具，能有效监控Windows、Linux和Unix的主机状态，交换机路由器等网络设置，打印机等。在系统或服务状态异常时发出邮件或短信报警第一时间通知网站运维人员，在状态恢复后发出正常的邮件或短信通知。 nagios主要的特征是监控告警，最强大的就是告警功能，可支持多种告警方式，但缺点是没有强大的数据收集机制，并且数据出图也很简陋，当监控的主机越来越多时，添加主机也非常麻烦，配置文件都是基于文本配置的，不支持web方式管理和配置，这样很容易出错，不宜维护。 03 Zabbix zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。zabbix能监视各种网络参数，保证服务器系统的安全运营；并提供强大的通知机制以让系统运维人员快速定位/解决存在的各种问题。 zabbix由2部分构成，zabbix server与可选组件zabbix agent。zabbix server可以通过SNMP，zabbix agent，ping，端口监视等方法提供对远程服务器/网络状态的监视，数据收集等功能，它可以运行在Li……
8 0 0 -
【Linux】文件的内核级缓冲区、重定向、用户级缓冲区(详解)
一.文件内核级缓冲区 在一个struct file内部还要有一个数据结构-----文件的内核级缓冲区 打开文件，为我们创建struct file，与该文件的所对应的操作表函数指针集合，还要提供一个文件的内核级缓冲区 1.write写入具体操作 当我们去对一个文件写入的时候，那么是如何进行写入的呢？ 比如上层调用write(3,"hello word",..),根据PCB找到file_struct,然后找到fd_array[]，然后拿到文件描述符表，找到目标3号 文件，然后把字符串“hello word”，拷贝到文件内核级缓冲区，write给我们进行拷贝，file会找到ops函数指针集合中write方法，然后通过这个方法，把我们文件内核及缓冲区的内容刷新到我们对应的外设中，当然由文件内核级缓冲区刷新到外设的过程什么时候刷新是由OS自主决定的， 所有write本质是一个拷贝函数，从用户拷贝到内核，文件这些数据结构都是OS给我们提供的。 这就是我们平时写文件的时候，比如word文档的时候，已经键盘里进行输入了，为什么最后还要进行保存，保存是在干什么？写只是把数据写到文件的内核级缓冲区，保存是把内容从缓冲区刷新到外设，这个过程叫做写入！！！ 补充：每个文件都有属于自己的文件操作表，都有属于自己的内核级缓冲区。 2.read读取具体操作 当我们去对一个文件写入的时候，那么是如何进行写入的呢？ 上层调用read(3,buffer,...)，在读的时候本质是在做什么呢？ 找到进程，找到文件描述符表，找到文件，然后他会检测当前数据是在文件内核级缓冲区内，还是在磁盘上，如果在读的时候，数据没在缓冲区里面，就会触发我们read方法，把数据从磁盘读到缓冲区里，然后read开始进行把缓冲区里的数据拷贝到buffer中。 读到缓冲区之后，才能完成拷贝，这个过程，很明显就会阻塞住，这就是我们平常调read会阻塞的原因， 最典型scanf，调用scanf时，scanf对应的外设中根本没有数据，此时调……
12 0 0 -
【Linux庖丁解牛】—软件安装&vim！
1、Linux中的软件安装 Linux中一般有三种方式安装软件： a、源码安装 在Linux系统中，源码安装虽然提供了高度的灵活性和定制性，但也存在一些明显的缺陷。以下是对这些缺陷的详细归纳： 安装过程复杂： 源码安装需要用户手动下载源代码、解压、配置、编译和安装，整个过程相对繁琐。 尤其是在安装较大的软件集合（如LAMP环境）时，步骤更多，容易出现拼写错误等问题。 编译时间长： 源码安装需要编译源代码，这个过程通常需要较长的时间，特别是对于大型软件来说，编译时间可能非常长。 这增加了用户等待的时间成本，也降低了安装效率。 报错解决困难： 由于源码安装涉及多个步骤和工具（如gcc编译器、make编译命令等），一旦在安装过程中报错，新手用户可能难以解决。 这需要用户具备一定的编程和技术知识，以及一定的错误排查和解决问题的能力。 依赖管理复杂： 源码安装通常需要用户手动解决软件依赖问题，这增加了安装的复杂性和不确定性。 如果依赖项没有正确安装或配置，可能会导致软件无法正常运行。 卸载不便： 虽然源码安装的软件可以通过删除安装目录来实现完全卸载，但如果用户在安装时没有指定明确的安装路径，或者将文件分散存储在多个目录中，卸载过程可能会变得复杂和困难。 缺乏统一的包管理： 与二进制包安装相比，源码安装缺乏统一的包管理系统来管理软件的安装、升级、查询和卸载等操作。 这使得用户在管理多个软件时可能会遇到一些不便和混乱。 b、软件包安装——rpm 在Linux系统中，软件包安装虽然提供了丰富的功能和灵活性，但也存在一些潜在的缺陷。以下是对Linux中软件包安装缺陷的详细归纳： RPM（Red Hat Package Manager）是一种软件包格式，广泛用于Red Hat、CentOS等基于RPM的Linux发行版。RPM包安装也存在一些缺陷： 依赖关系复杂：RPM包安装时，如果遇到依赖问题，需要用户手动解……
7 0 0
中间件
