OS_lab0实验报告
os_lab0实验报告
第一部分:课下思考题
Thinking 0.1
Q:
-
在/home/20xxxxxx/learnGit目录下创建一个名为README.txt的文件。这时使用 git status > Untracked.txt 。
-
在 README.txt 文件中随便写点什么,然后使用刚刚学到的 add 命令,再使用 git status > Stage.txt 。
-
之后使用上面学到的 Git 提交有关的知识把 README.txt 提交,并在提交说明里写入自己的学号。
-
使用 cat Untracked.txt 和 cat Stage.txt,对比一下两次的结果,体会一下README.txt 两次所处位置的不同。
-
修改 README.txt 文件,再使用 git status > Modified.txt 。
-
使用 cat Modified.txt ,观察它和第一次 add 之前的 status 一样吗,思考一 下为什么? (对于Thinking 0.1,只有这一小问需要写到课后的实验报告中)**
A:
经操作三次cat输出分别如下
>>>Untracked files: >>>Changes to be committed: >>>Changes not staged for commit:
可以发现第一次在工作区创建README.txt,并没有add到工作区,因此是Untracked files,而之后add到git版本区,就被跟踪了,但是还没有提交因此显示Changes to be committed:,最后commit之后却修改了README.txt,需要再次add、commit之后才能提交。
Thinking 0.2
Q:
仔细看看这张图,思考一下箭头中的 add the file、stage the file 和 commit 分别对应的是 Git 里的哪些命令呢?
A:
**add the file即将文件由本地库添加到暂存区和objects 即 **
git add <file>
stage the file 表示将工作区的文件(已修改但是未提交)提交至暂存区(覆盖暂存区已有的对应文件)即
git add [file]
commit表示将已暂存的文件提交,对应
git commit -m "[discribtion]"
Thinking 0.3
Q:
- 深夜,小明在做操作系统实验。困意一阵阵袭来,小明睡倒在了键盘上。等到小明早上醒来的时候,他惊恐地发现,他把一个重要的代码文件printf.c删除掉了。苦恼的小明向你求助,你该怎样帮他把代码文件恢复呢?
- 正在小明苦恼的时候,小红主动请缨帮小明解决问题。小红很爽快地在键盘上敲下了git rm printf.c,这下事情更复杂了,现在你又该如何处理才能弥补小红的过错呢?
- 处理完代码文件,你正打算去找小明说他的文件已经恢复了,但突然发现小明的仓库里有一个叫Tucao.txt,你好奇地打开一看,发现是吐槽操作系统实验的,且该文件已经被添加到暂存区了,面对这样的情况,你该如何设置才能使Tucao.txt在不从工作区删除的情况下不会被git commit指令提交到版本库?
A:
#1
git checkout -- printf.c
#2
git reset HEAD [--] printf.c #帮我们从版本库中 拉取文件到 暂存区
git checkout --cached printf.c
#3
##如果未commit
git rm --cached Tucao.txt#从暂存区删除Tucao.txt
E:
以下实例从暂存区和工作区中删除 runoob.txt 文件:
git rm runoob.txt
如果删除之前修改过并且已经放到暂存区域的话,则必须要用强制删除选项 -f。
强行从暂存区和工作区中删除修改后的 runoob.txt 文件:
git rm -f runoob.txt
如果想把文件从暂存区域移除,但仍然希望保留在当前工作目录中,换句话说,仅是从跟踪清单中删除,使用 --cached 选项即可:
git rm --cached <file>
Thinking 0.4
Q:
- 找到我们在/home/20xxxxxx/learnGit下刚刚创建的README.txt,没有的话就新建一个。
- 在文件里加入Testing 1,add,commit,提交说明写 1。
- 模仿上述做法,把1分别改为 2 和 3,再提交两次。
- 使用 git log命令查看一下提交日志,看是否已经有三次提交了?记下提交说明为 3 的哈希值1。
- 开动时光机!使用 git reset --hard HEAD
^
,现在再使用git log,看看什么没了? - 找到提交说明为1的哈希值,使用 git reset --hard
,再使用git log,看看什么没了? - 现在我们已经回到过去了,为了再次回到未来,使用 git reset --hard
,再使用git log,我胡汉三又回来了! - 这一部分在课后的思考题中简单写一写你的理解即可,毕竟能够进行版本的恢复是使用git很重要的一个原因。
A:
这条指令就是让我们可前进,可后退。它有两种用法,第一种是使用 HEAD 类似形 式,如果想退回上个版本就用 HEAD^,上上个的话就用 HEAD^^,当然要是退 50 次 的话写不了那么多^,可以使用 HEAD~50 来代替。第二种就是使用我们神器 Hash 值, 用 Hash 值不仅可以回到过去,还可以“回到未来”。
$ git reset HEAD^ # 回退所有内容到上一个版本
$ git reset HEAD^ hello.php # 回退 hello.php 文件的版本到上一个版本
$ git reset 052e # 回退到指定版本
$ git reset --hard <hashcode># 回退到hashcode对应的版本
Thinking 0.5
Q:思考下面四个描述,你觉得哪些正确,哪些错误,请给出你参考的资料或实验证据。
- 克隆时所有分支均被克隆,但只有HEAD指向的分支被检出。
- 克隆出的工作区中执行 git log、git status、git checkout、git commit等操作不会去访问远程版本库。
- 克隆时只有远程版本库HEAD指向的分支被克隆。
- 克隆后工作区的默认分支处于master分支。
A:
1.正确。Git 克隆的是该 Git 仓库服务器上的几乎所有数据,而不是仅仅复制完成你的工作所需要文件。 当你执行 git clone
命令的时候,默认配置下远程 Git 仓库中的每一个文件的每一个版本都将被拉取下来。 `
2.正确 因为已经全都拉取下来了
3.错误 应该是远程仓库均被克隆
4.正确
Thinking 0.6
Q:
执行如下命令,并查看结果
echo first
echo second > output.txt
echo third > output.txt
echo forth >> output.txt
A:
CMD1 > <file>
表示将CMD1的输出重定向到file,但是会覆盖原本的file里的内容
CMD2 >> <file>
表示将CMD2的输出重定向到file,但是会将CMD1的输出驾到file的最后,即不会覆盖
Thinking 0.7
Q:
使用你知道的方法(包括重定向)创建下图内容的文件(文件命名为test),将创建该文件的命令序列保存在command文件中,并将test文件作为批处理文件运行,将运行结果输出至result文件中。给出command文件和result文件的内容,并对最后的结果进行解释说明(可以从test文件的内容入手). 具体实现的过程中思考下列问题: echo echo Shell Start 与 echo `echo Shell Start'效果是否有区别; echo echo \$c>file1 与 echo `echo \$c>file1'效果是否有区别.
A:
command
echo echo Shell Start…> test
echo echo set a=1 >> test
echo a=1 >> test
echo echo set b=2 >>test
echo b=2 >> test
echo echo set c=a+b >> test
echo c=\$[\$a+\$b] >> test
echo echo c=\$c >> test
echo echo save c to ./file1 >>test
echo echo \$c\>file1 >>test
echo echo save b to ./file2 >>test
echo echo \$b\>file2 >>test
echo echo save a to ./file3 >>test
echo echo \$a\>file3 >>test
echo echo save file1 file2 file3 to file4 >>test
echo cat file1\>file4 >>test
echo cat file2\>\>file4 >>test
echo cat file3\>\>file4 >>test
echo echo save file4 to ./result >>test
echo cat file4\>\>result >>test
result
3
2
1
直接执行echo echo Shell Start与 echo 'echo Shell Start'
效果没有区别
把这两条语句的结果写入test.txt也没有区别
但是把两条语句的结果写入test结果不同,
一个写入echo Shell Start
一个写入'echo Shell Start'
echo echo \$c>file1
是把echo $c的内容写入file1
echo 'echo \$c>file1'
是把echo $c>file1输出到屏幕
第二部分:实验难点
E 0.3
1.在lab0工作区的ray/sh_test2目录下,存在一个未补全的search.sh文件,将其补完,以实现通过指令bash search.sh file int result,可以在当前文件夹下生成result文件,内容为file文件所有含有int字符串对应的行数,即若有多行含有int字符串需要全部输出。[注意:对于指令bash search.sh file int result,file及result可为任何合法文件名称,int可为任何合法字符串,若已有result文件,则将其原有内容覆盖,匹配时大小写不忽略]
这个小题需要完成三步任务:
- 在file中寻找所有包含"int"字符串的行并输出出来
- 将输出的line:"int"内容切割获取第一个参数
- 将获取的参数重定向到result文件中
因此我们采用如下命令执行
grep -n "$2" $1 | awk -F ':' '{print $1}' >> $3
E 0.4
2.lab0工作区的csc/code/fibo.c成功更换字段后(bash modify.sh fibo.c char int),现已有csc/Makefile和csc/code/Makefile,补全两个Makefile文件,要求在csc目录下通过指令make可在csc/code文件夹中生成fibo.o、main.o,在csc文件夹中生成可执行文件fibo,再输入指令make clean后只删除两个.o文件。[注意:不能修改fibo.h和main.c文件中的内容,提交的文件中fibo.c必须是修改后正确的fibo.c,可执行文件fibo作用是从stdin输入一个整数n,可以输出斐波那契数列前n项,每一项之间用空格分开。比如n=5,输出1 1 2 3 5]
我们观察文件结构如下:
|-- csc
| |-- Makefile
| |-- code
| | |-- Makefile
| | |-- fibo.c
| | |-- main.c
| | `-- modify.sh
| |-- fibo
| `-- include
| `-- fibo.h
为了完成题目要求,我们需要以下步骤:
- 在ccs/下调用Makefile可以对csc/code/下的fibo.c和main.c进行编译,链接,这里需要借助csc/include/fibo.h
- 然后将fibo.o和mian.o链接生成fibo可执行文件到csc/下
- 最后调用csc/Makefile的make clean可以删除csc/code/下的fibo.o和main.o
- 大功告成!
第三部分:体会与感想
- 由于先前没有接触过shell、Makefile、vim、grep、awk等,于是画了较长时间在预置知识的学习
- 实验部分E 0.3和E 0.4感到困难,上网搜索重定向、Makefile和GCC编译相关指令知识可以轻松解决
- 个人感觉预置知识繁多冗长,应该较为提前的给予同学们平台去学习,不然内容太多,很难短时间消化