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

Bash不写历史

Bash历史记录功能允许用户查看和重复之前在终端中执行的命令。如果你希望Bash不记录历史命令,可以通过以下几种方式实现:

基础概念

Bash的历史记录功能通过读取和写入~/.bash_history文件来工作。每次用户登录或退出时,Bash会自动保存和加载历史命令。

相关优势

  • 提高效率:通过查看历史命令,用户可以快速重复之前执行过的命令。
  • 便于调试:历史记录有助于追踪和理解之前的操作步骤。

类型与应用场景

  • 临时禁用:在某些敏感操作或测试环境中,可能需要临时禁用历史记录功能。
  • 永久禁用:对于某些特定的使用场景,如自动化脚本或特定用户账户,可能希望永久禁用历史记录。

如何实现Bash不写历史

临时禁用历史记录

在当前终端会话中临时禁用历史记录,可以使用以下命令:

代码语言:txt
复制
unset HISTFILE

这会使得当前会话不再记录历史命令。

永久禁用历史记录

要永久禁用历史记录,可以编辑用户的Bash配置文件(通常是~/.bashrc~/.bash_profile),添加以下内容:

代码语言:txt
复制
export HISTFILE=/dev/null

这样设置后,每次启动新的终端会话时,Bash都会将历史记录文件设置为/dev/null,即丢弃所有历史记录。

遇到的问题及解决方法

问题:即使设置了HISTFILE=/dev/null,历史记录仍然存在。

原因:可能是由于之前的会话已经生成了历史记录文件,或者有其他配置覆盖了当前设置。 解决方法

  1. 手动删除~/.bash_history文件:
  2. 手动删除~/.bash_history文件:
  3. 确保在所有相关的Bash配置文件中都设置了HISTFILE=/dev/null,例如检查~/.bashrc~/.bash_profile等。

通过上述方法,可以有效控制Bash是否记录历史命令,根据具体需求选择合适的配置方式。

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

相关·内容

(16)Bash历史命令与补全

1.历史命令history [root@laptop~]#history [选项] [历史命令保存文件] 选项: -c:清空历史命令 -w:把缓存中的历史命令写入历史命令保存文件 (默认保存在...“ ~/.bash_history ”) PS:历史命令默认会保存1000条,可以在环境变量配置文件/etc/profile中进行修改,找到HISTSIZE=1000进行修改,修改之后重新登录使配置文件生效...2.历史命令的调用 ①使用上、下箭头调用以前的历史命令 ②使用“!...n”重复执行第n条历史命令 #重复执行第369条命令 [root@laptop~]#!369 ③使用“!!”重复执行上一条命令 #重复执行上一条命令[root@laptop~]#!! ④使用“!...ser 3.命令与文件补全 在Bash中,命令与文件补全是非常方便与常用的功能,我们在输入命令或文件时,如果命令或文件是以我们输入的字符开头并且是唯一的,按“Tab”键就会自动进行补全;如果没有补全,

79710

nodejs写bash脚本终极方案!

◆ 前言 最近在学习bash脚本语法,但是如果对bash语法不是熟手的话,感觉非常容易出错,比如说:显示未定义的变量shell中变量没有定义,仍然是可以使用的,但是它的结果可能不是你所预期的。...后来就开始探索,如果用node脚本代替bash该多好啊,经过一天折腾逐渐发现一个神器,Google旗下的zx库,先别着急,我先不介绍这个库,我们先看看目前主流用node如何编写bash脚本,就知道为啥它是神器了...0) { shell.echo('Error: Git commit failed'); shell.exit(1); } 从上面代码上看来,shelljs真的已经算是非常棒的nodejs写bash...echo 2`, $`sleep 3; echo 3`, ]) let name = 'foo bar' await $`mkdir /tmp/${name} 各位看官觉得咋样,是不是就是在写linux...usr/bin/bash' $.quote 指定用于在命令替换期间转义特殊字符的函数 默认用的是 shq 包.

3.9K20
  • nodejs 写 bash 脚本终极方案!

    前言 最近在学习bash脚本语法,但是如果对bash语法不是熟手的话,感觉非常容易出错,比如说:显示未定义的变量shell中变量没有定义,仍然是可以使用的,但是它的结果可能不是你所预期的。...后来就开始探索,如果用node脚本代替bash该多好啊,经过一天折腾逐渐发现一个神器,Google旗下的zx库,先别着急,我先不介绍这个库,我们先看看目前主流用node如何编写bash脚本,就知道为啥它是神器了...shell.echo('Error: Git commit failed'); shell.exit(1); } 复制代码 从上面代码上看来,shelljs真的已经算是非常棒的nodejs写bash...2`, $`sleep 3; echo 3`, ]) let name = 'foo bar' await $`mkdir /tmp/${name} 复制代码 各位看官觉得咋样,是不是就是在写linux...shell = '/usr/bin/bash' 复制代码 $.quote 指定用于在命令替换期间转义特殊字符的函数 默认用的是 shq 包.

    2.6K20

    测试用例,写不写?

    有的观点认为,现在是敏捷研发,测试都来不及,写什么测试用例。 折中的观点认为测试用例可以写,但是不需要写的那么详细,用导图写个大概就可以了。 你认可哪种观点呢?...常见例如等价类、边界类及错误推测法等等,在这里不展来说啦,网上有太多的资料。文章底部还会推荐一篇关于测试用例设计的“兵器谱”。...如果团队成员的能力较强时,我们只需要罗列出测试点即可,依托于个人的测试经验,来节约编写测试用例的时间成本,但不可以不写用例,它能在你疏忽的时候提醒到你还有哪些测试需要执行。...用例“前置条件”不一定能轻易实现 我们在写用例时,一般都会写前置条件,在用例中写起来可能只是一句话,但这些前置条件其实并不是那么容易构建出来的,比如一些支付场景、审批流、第三方回传数据,甚至于异常场景等等

    40210

    测试用例,写不写?

    有的观点认为,现在是敏捷研发,测试都来不及,写什么测试用例。 折中的观点认为测试用例可以写,但是不需要写的那么详细,用导图写个大概就可以了。 你认可哪种观点呢?...常见例如等价类、边界类及错误推测法等等,在这里不展来说啦,网上有太多的资料。文章底部还会推荐一篇关于测试用例设计的“兵器谱”。...如果团队成员的能力较强时,我们只需要罗列出测试点即可,依托于个人的测试经验,来节约编写测试用例的时间成本,但不可以不写用例,它能在你疏忽的时候提醒到你还有哪些测试需要执行。...用例“前置条件”不一定能轻易实现 我们在写用例时,一般都会写前置条件,在用例中写起来可能只是一句话,但这些前置条件其实并不是那么容易构建出来的,比如一些支付场景、审批流、第三方回传数据,甚至于异常场景等等

    46220

    linux中清除bash命令行历史记录

    bash 历史记录记录了用户在 Linux 命令行上执行的所有命令。这允许你使用键盘的上up arrow或者键盘的下down arrow键滚动查看命令历史文件。...在本文中,我们将向你展示两种在 Linux 系统上清除命令行历史记录的简单方法。 例如,如果你输入了一个包含纯文本密码的命令,并且你不希望其他系统用户或攻击者看到此密码,则需要删除或清除历史文件。...$ sudo mysql -u root -p123456 如果你在最后查看bash历史文件,你会看到上面输入的密码。.../.bash_history. $ ls -l /home/rumenz/.bash_history 要从历史文件中删除一行,请使用该-d选项。...$ cat /dev/null > ~/.bash_history Note: 普通用户只能查看自己的命令历史,但是root用户可以查看系统中所有其他用户的命令历史。

    3.1K20

    写与不写:程序员对代码注释之争

    写与不写:程序员对代码注释之争 博主 默语带您 Go to New World....⌨ 《写与不写:程序员对代码注释之争》 摘要 在程序员的世界里,注释常常成为了讨论的焦点。据说,程序员最烦的两件事是别人不写注释以及自己要写注释。为何写注释在开发过程中如此关键?...而且,我认为,写注释也是一种对自己和他人负责的态度。 2. 你认为程序员不写注释的原因是什么 2.1 追求编写的速度 很多时候,程序员会因为项目的紧迫时间线而牺牲注释。...根据一个开发者调查,40%的程序员不写注释的原因是他们认为他们的代码是“自解释的”。...在实际的开发过程中,一个程序员可能会受到多种因素的影响,导致他们不写注释。但无论原因是什么,都不能否认注释在软件开发中的重要性。 3.

    8310

    好程序员不写代码

    程序员写多少代码不重要,重要的是解决问题的效率。 不用你写、不用你维护的才是好代码——直接用的现成解决方案嘛。 简单几句话,仿佛说到了众多同行的心坎里。...圣诞之后新年之前的垃圾时间里,他这条不总结不展望不拜年的Twitter,已经被转发了700多次,收获了2100多赞。 多写代码就是好?...不要重复造轮子 这句话在各行各业都深入人心,程序员界也不例外。 作为Keras这个高级框架的作者和布道者,Chollet对重复造轮子这种行为,更是持之以恒地批判。...One More Thing 知乎上曾经流传着这样一个问题:程序员真的很少写代码吗? 有网友嘲讽&自黑,说写代码多、天天敲键盘的程序员是“苦力”、“段位不够”。...话说回来,无论调框架还是从头搭、写文档还是找bug,都是为了实现功能。 你支持有码还是无码呢? — 完 —

    72520

    7个实用的Bash历史快捷方式【Linux-Command line】

    这些必不可少的Bash快捷键可作用在命令行上以节省时间。 command_line_prompt.png 大多数Bash历史快捷方式指南都详尽列出了每个可用的条目。...trick,那些我第一次开始使用Bash时就学到的技巧。 因此,快捷键中的大部分都未被记住。 本文概述了我每天实际使用的快捷方式。...它基于我的书--《Learn Bash the hard way》中的某些内容。 你可以预览本书以了解更多信息。 当人们看到我使用这些快捷方式时,他们经常问我:“你在那做了什么!?”...之后插入“-n”:(其中n是要在历史记录中返回的命令数)。...如果你想更深入地了解Bash的全部知识,拿起我的书,《Learn Bash the hard way》或查看我的在线课程Master Bash shell。

    86710

    【测试基础】每天这么忙,到底写不写测试用例?

    不少公司项目都是快速迭代的,会没有足够时间写测试用例,但我们也最好用XMind去梳理一遍测试点。等项目结束或有时间时,把测试用例补上是最好的。切记:一定要梳理测试点,以免上线出现漏测等问题。...而我们要怎么写呢? 1、首先来看看它的官方定义:是为项目需求而编制的一组 测试输入、执行条件以及预期结果,以使某个程序是否满足客户需求。...uat--验收测试) 2.测试项目 注释:对应一个功能模块(细分功能)--子项目 3.测试标题 注释:直接对测试点进行细化得出,输入内容+结果,同一功能模块标题不能重复(来自测试点),建议一行写一个测试点...想到一个问题,也是大多数人都遇到过的问题,那就是遇到隐形需求如何写用例(需求不明确)?

    38830

    远离不写注释的程序员

    写注释的程序员才是好程序员 问:程序员最讨厌什么样的同事? 答:不写注释 问:程序员最讨厌干什么?...答:写注释 这仿佛成了一个死循环 大家都有过这样的经历 灵感上来了,疯狂敲代码 大几百行写完 真有成就感 但是队友不高兴了 没注释看不明白 所以,现在是否写注释 已经从行业约束问题 降低到最基本的道德问题了...System.out.println(secretText); // 输出结果 } 有注释之后 整个代码理解会更清晰 但是实际工作中 除了部分复杂算法 其实没有必要写到这么细 所以大部分时候 都建议写文档注释...包括 类、属性、方法等 JavaDoc标记 Java语言有一套专门的注释规则 可以形成标准文档 写的时候类似这样 /** * 这是一个示例接口 */ public interface IMessageService...打开导出目录下的index.html 就能浏览文档了 可以看到前面我们所写的注释 都体现在文档当中了 这个文档非常规范 可以遍历项目层次 清晰、干净 很多开源项目的说明书 都是用它做的 非常优秀 写注释的人不一定更优秀

    19540

    CTO不写代码,真的可以吗?

    到底写不写代码?该不该做代码评审(Code Review),亲力亲为给程序员做出榜样?还是把握一下大方向,设计架构,管管程序员,提供一些培训?...这个坐标轴最左面是操作一级的,比如说写代码、测试网络、测试、搭防火墙、写脚本等等,到中间是管理上的事,再往右边是领导上的事情。...是写代码的人管,还是 CTO 管? 在这种情况下,CTO 还要不要写代码,CTO 如果写了代码谁来管上面这些事?我粗浅地给大家归归类,CTO 应该干什么,CTO 该聚焦什么。...还有采取小团队制度,不超过 8 到 10 个人,因为手就十个手指,多一个就需要这个人有特别的训练,每增加一个是一个指数级的增加。

    1.5K40

    为什么我不建议你写注释?

    并不是不让你真的不用注释,而是有些时候,用注释是因为我们怕其他的开发者在我们的代码的时候,看不懂我们的代码从而去加注释,那么我们为什么不写出其他开发者一目了然的代码呢?...为什么不建议写注释? 为什么我们极力贬低注释?因为注释跟代码一样,注释会撒谎,但这并不是我们有意的写一些撒谎的注释。...写注释的常见动机之一是因为糟糕代码的存在,我们编写一个方法,写完之后发现这个方法内容乱七八糟,这个时候我们可能会告诉自己,在上面写点注释!但是错了,最好的方法是让代码变得干净!...带有少量注释的整洁而有表达力的代码,比带有大量注释的零碎而又复杂的代码像样的多,与其花时间编写解释你写的代码的注释,倒不如花时间清洁你那堆糟糕的代码。 如何用代码来阐述? 你愿意看到这个?...然而有些时候,一些废话的注释我们不要去写 比如 public class Demo { // Default constructor public Demo () { }

    1.2K20
    领券