Linux 开发别再卡壳!makefile/git/gdb 全流程实操 + 作业解析,新手看完直接用----《Hello Linux!》(5)

Linux 开发别再卡壳!makefile/git/gdb 全流程实操 + 作业解析,新手看完直接用----《Hello Linux!》(5)

文章目录

前言

做 Linux 开发时,你是不是也遇到过这些 “卡脖子” 时刻?写 makefile 时,明明语法没错却报错,最后发现是依赖方法行没加 Tab;想提交代码到 gitee,记不清 git add/commit/push 的 “三板斧”,还得反复搜教程;用 gdb 调试程序,输了命令没反应,才想起编译时没加-g生成 debug 版本;甚至连写个进度条,都搞不懂\r和\n的区别,导致进度条乱跳……

其实这些问题,本质是没把 Linux 开发的 “核心工具链” 和 “底层逻辑” 串起来。比如 makefile 不只是写依赖关系,还得懂.PHONY的作用;git 提交不只是敲命令,还得知道git config配置的必要性;gdb 调试不只是记指令,还得清楚 debug 版本和 release 版本的区别。

这篇文章就是给 Linux 新手的 “实战指南”,把开发中高频用到的工具和知识讲透:
拆解 makefile 的核心规则(依赖关系、特殊符号 @ / @/ @/^、.PHONY用法),帮你避开 “Tab 报错”“重复编译” 的坑;
带写 Linux 进度条代码,讲清回车换行(\r/\n)和缓冲区的底层逻辑,再也不怕进度条乱闪;
梳理 git 完整流程(安装→克隆→提交→推送到远程),包括第一次提交的git config配置细节;
总结 gdb 常用调试指令(断点、变量查看、函数跳转),明确 “必须用 debug 版本” 的前提;
最后附上 5 道高频作业题 + 解析,帮你巩固知识点(比如 yum 命令区别、编译阶段划分)。

每个工具都附具体命令和代码示例,每个易踩的坑都标红提醒。不管你是刚学 Linux 的学生,还是需要用 Linux 做开发的新人,跟着走一遍,就能摆脱 “遇事就搜” 的困境,把这些核心工具用得顺手又扎实。

make/makefile

make是一个命令

语法:make 目标文件名eg: make clean

makefile是一个文件(引申:创建Makefilemakefile都行)(要跟使用命令的文件放在同一目录下)
一些术语:

1.这个是在makefile里面的写法,第一个文件叫做目标文件,第二个文件叫做依赖文件(可以不止一个)

第一行是他们的依赖关系(这里是text依赖于text.c

第二行是他们的依赖方法(也可以有多个)

引申:依赖方法那行必须要一个Tab键开头,不能4个空格这样(回车后会自动给上这个Tab)
makefile的工作规则:

1.如果是clean的话,不用写依赖文件 这个的作用就是清除所有的目标文件

引申:在依赖关系前面加上.PHONY可以让这个make的时候不判断


clean常会加上这个
make的工作规则:

1.makefile里面的第一个出现的文件名是第一个目标文件,可以直接用make来调用生成

2.make会自动推导makefile里面的依赖关系比如这里的话,如果输入make mycode,就会把这些全部执行一遍

3.make会根据源文件和目标文件的新旧,判定是否需要重新执行依赖关系进行编译

(也就是多次make同一个目标文件(makefile里的关系和方法也没改动的话),make会判断源文件有没有被改过来决定要不要把可执行程序做改动)这样做的目的:提高编译效率

make怎么做到这个的:因为源文件的最近修改时间一般比可执行文件要老

引申:有的对可执行程序做改动只是在可执行程序上增加或删除内容,不会重新生成–所以还是clean之后再make生成会好些
一些特殊符号:

1.@加在依赖方法那可以让依赖方法不在make之后回显


2.$@$^ 在依赖方法里可以用来分别表示目标文件和依赖文件

(eg:如果目标或依赖文件是多个的话,那就代表的是全部)


3.lib=libmymath.a表示定义变量lib,里面存着名字libmymath.a
引申:如果想绑定执行的话,可以eg:

文件的三个时间

Access是最近的一次访问时间(多次访问时才会更新)

Modify是最近的一次文件内容修改的时间

Change是最近的一次文件属性修改的时间(引申:文件的大小也算文件属性)

引申:
这个看到的时间是Modify的那个时间

make判断是否要把可执行程序做改动的时间也是看的Modify的那个时间

Linux第一个小程序-进度条

回车和换行

回车:是到该行的开头\r

换行是到下一行的现在这个位置

\n本来是换行的,但是现在一般把他处理成回车换行

缓冲区

比如:stdout是行缓冲,在没换行之前,一般会把要stdout的东西先存在缓冲区,等程序结束啥的会释放(当然,用fflush也能让他出来)

但是eg:Windows下的话一般显示不出来这个缓冲现象

程序的代码展示

intmain(){int i =0;char bar[102];memset(bar,0,sizeof(bar));constchar*lable="|/-\\";//注意这里的这个就是可以形成会旋转的小圆圈while(i <=100){printf("[%-100s][%d%%][%c]\r", bar, i, lable[i%4]);//注意这里字符数组用%s占位的话,会把数组里的东西全打印出来//%%改成\%也行哈fflush(stdout); bar[i++]='#';usleep(10000);//usleep是微秒,sleep是秒}printf("\n");return0;}
CPP中:两个紧连的字符串常量(用双引号括起来的字符串)会被编译器自动合并成一个字符串

git指令

 安装git: yum installgit 克隆远程仓库到本地: git clone [项目的链接] 引申: git --version可以看到当前git的版本--判断装没装好git 三板斧: gitadd 文件名 -- 添加指定文件 gitadd. 添加当前目录所有修改(不包括被忽略的文件) git commit -m "提交日志"(提交日志修改不了的,不要乱写!)git push git log可以查看提交记录 git status可以看当前仓库的状况(比如三板斧进行到哪一步了) (这俩都需要在git仓库目录或子目录下才能用哈) 
在这里插入图片描述
想上传的文件要存在目录下有.git的那个目录下才行
在第一次用git commit时会弹出这个:

需要我们输入git config那两行的东西(那个邮箱最好写自己gitee绑定的邮箱,不然那个小绿点不会算自己的)

为什么会有这个规定:这样才好对代码进行溯源看是谁写的

注意:git push这里的用户名要输入这里的这个


最好现在不要学免密提交,对想熟悉流程新手起不到锻炼作用

关于gitee

在创建仓库时的.gitignore其实就是可以在上传到远程仓库时自动省略一些后缀的文件上传上去(自己也可以对.gitignore里面的东西进行增删查改, 注意区分.d和*.d

创建仓库的话,当前阶段的话,设置模板选择Readme就行了

注意:传代码的话,传头文件和源文件就行,不要传可执行程序上去啥的

Linux调试器-gdb使用

前提:想被gdb调试,必须要以debug形式发布才行

语法:gdb 可执行程序的名字 这里的话,就算在当前目录下,也要写相对路径或绝对路径,比如:./text
这里只有简写,那种长的写法没写

l 行号:显示这个文件的源代码,从改行号往下列,每次列10行。(想往下就敲回车)

l 函数名:列出里面某个函数的源代码。

n:单条执行。(也就是单行执行,除非那行没语句eg:只有一个{)

s:进入函数调用

b 行号:在某一行设置断点

b 函数名:在某个函数开头设置断点

info b:查看断点信息。



finish:执行到当前函数返回

p 变量:打印变量值。

set var:修改变量的值

c:跳到下一个断点的位置

r:从头开始运行程序直到碰到断点停止

d:删除所有断点

d 断点序号:删除序号为这个的断点

disable 断点序号:关闭这个断点

enable 断点序号:启用这个断点

display 变量名:跟踪查看一个变量,每次停下来都显示它的值

set var 变量名 = 新值:修改该变量名的值(只在这次调试中生效)

undisplay 跟踪的序号:取消对先前设置的那些变量的跟踪

until X行号:跳至X行

info locals:查看当前栈帧局部变量的值

bt:查看各级函数调用及参数

比如:
q或者ctrl+d:退出gdb
多文件生成的可执行程序怎么打断点:

这个时候就要指定源文件来打断点了
引申:一般很少用调试,除非迫不得已

一般是通过打印某些地方的值来代替调试

作业部分

以下命令正确的是:(ABC) A.yum makecache命令的功能是将服务器的软件包信息缓存到本地 B.yum search命令可以在所有软件包中搜索包含有指定关键字的软件包 C.yum clean all 命令可以清除缓存中老旧的头文件和软件包 D.yum upgrade命令可以更新所有的rpm软件包 //yum -y update:升级所有包同时,也升级软件和系统内核;//yum -y upgrade:只升级所有包,不升级软件和系统内核,软件和内核保持原样
 Vi编辑器中,怎样将字符AAA全部替换成yyy?(B) A.p/AAA/yyy/ B.s/AAA/yyy/g C.i/AAA/yyy/ D.p/AAA/yyy/h 
 下列关于makefile描述正确的有?(ABC) A.makefile文件保存了编译器和连接器的参数选项 B.主要包含了五个东西:显式规则、隐晦规则、变量定义、文件指示和注释 C.默认的情况下,make命令会在当前目录下按顺序找寻文件名为“GNUmakefile”、“makefile”、“Makefile”的文件, 找到了解释这个文件 D.在Makefile不可以使用include关键字把别的Makefile包含进来 
程序的完整编译过程分为是:预处理,编译,汇编等,关于编译阶段的编译优化的说法中不正确的是(A) A.死代码删除指的是编译过程直接抛弃掉被注释的代码 //指的是移除根本执行不到的代码,或者对程序运行结果没有影响的代码 B.函数内联可以避免函数调用中压栈和退栈的开销 C.for循环的循环控制变量通常很适合调度到寄存器访问 D.强度削弱是指执行时间较短的指令等价的替代执行时间较长的指令 
 在编译过程中,产生parse tree的过程是哪个阶段?(A) A.语法分析 B.语义分析阶段 C.词法分析 D.目标代码生成阶段 

Read more

Linux 进程间通信之命名管道(FIFO):跨进程通信的实用方案

Linux 进程间通信之命名管道(FIFO):跨进程通信的实用方案

🔥草莓熊Lotso:个人主页 ❄️个人专栏: 《C++知识分享》《Linux 入门到实践:零基础也能懂》 ✨生活是默默的坚持,毅力是永久的享受! 🎬 博主简介: 文章目录 * 前言: * 一. 命名管道核心概念:什么是 FIFO? * 1.1 命名管道的定义 * 1.2 命名管道的核心特性 * 1.3 命名管道和匿名管道的区别与联系 * 二. 命名管道的创建方式 * 2.1 命令行创建(mkfifo 命令) * 2.2 代码创建(mkfifo 函数) * 三. 命名管道的打开规则(关键!) * 四. 命名管道实战案例 * 4.1 案例 1:命名管道实现文件拷贝 * 4.1.

By Ne0inhk
Flutter 组件 flutter_sheet_localization 的适配 鸿蒙Harmony 实战 - 驾驭云端词典自动化、实现鸿蒙端国际化词条无感更新与多语言 Key 生成方案

Flutter 组件 flutter_sheet_localization 的适配 鸿蒙Harmony 实战 - 驾驭云端词典自动化、实现鸿蒙端国际化词条无感更新与多语言 Key 生成方案

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 flutter_sheet_localization 的适配 鸿蒙Harmony 实战 - 驾驭云端词典自动化、实现鸿蒙端国际化词条无感更新与多语言 Key 生成方案 前言 在鸿蒙(OpenHarmony)生态的全球化应用开发中,面对上百个涉及金融支付、法律协议以及动态营销文案的多语言(i18n)词条映射。如果仅仅依靠传统的本地 intl 方案 手动修改 .arb 或 .json 文件。那么不仅会导致开发与翻译团队之间的“沟通断层”。更会因为频繁的手动拷贝错误引发严重的生产事故。 我们需要一种“云端协同、本地免维护”的翻译生产艺术。 flutter_sheet_localization 是一套专注于将 Google Sheets(或是兼容的 CSV 系统)

By Ne0inhk
Flutter 组件 cool_linter 适配鸿蒙 HarmonyOS 实战:静态代码治理,构建极致规范的代码质量红线与防腐架构

Flutter 组件 cool_linter 适配鸿蒙 HarmonyOS 实战:静态代码治理,构建极致规范的代码质量红线与防腐架构

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 cool_linter 适配鸿蒙 HarmonyOS 实战:静态代码治理,构建极致规范的代码质量红线与防腐架构 前言 在鸿蒙(OpenHarmony)生态迈向大规模协作、涉及超大规模代码仓治理及高性能基座重构的背景下,如何确保每一行代码都符合严苛的性能准则与安全规范,已成为决定系统长期稳定性的“架构防火墙”。在鸿蒙设备这类强调 AOT 极致优化与内存足迹(Memory Footprint)管控的环境下,如果团队代码依然充斥着魔法数字(Magic Numbers)、过度嵌套的逻辑块或泛滥的 dynamic 调用,由于由于静态分析缺失,极易由于由于“隐性技术债”导致线上环境不可预知的性能崩塌或内存泄漏。 我们需要一种能够深度定制规则、支持循环复杂度分析且具备“强类型纠偏”能力的静态检测方案。 cool_linter 为 Flutter 开发者引入了超越原生 Linter 的严苛检测范式。它利用高级分析插件机制,

By Ne0inhk
Flutter for OpenHarmony: Flutter 三方库 fake_async 掌控时间的魔法,让鸿蒙异步单测快如闪电(单元测试加速神器)

Flutter for OpenHarmony: Flutter 三方库 fake_async 掌控时间的魔法,让鸿蒙异步单测快如闪电(单元测试加速神器)

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net 前言 在 OpenHarmony 应用的单元测试中,异步逻辑是一个避不开的难点。如果你的代码中有 Future.delayed(Duration(minutes: 5)),难道你在跑测试时真的要等上 5 分钟吗?或者如果你在测试一个复杂的动画状态流转,如何精确地模拟时间流逝了 125 毫秒? fake_async 是 Dart 测试工具链中的“时间胶囊”。它能在一个受控的环境中虚拟化时钟。你可以瞬间“拨快”时间,让那些原本需要漫长等待的异步操作立即执行,从而让你的鸿蒙单测运行速度提升千倍。 一、核心虚拟时间原理 它通过接管全局的 Zone,拦截了所有基于时间的调度任务。 elapse(5 mins) 测试用例 fakeAsync 闭包环境 挂起的延迟任务 (Future/Stream) 瞬间拨快虚拟时钟

By Ne0inhk