Questions tagged «text-processing»

通过程序,脚本等操作或检查文本

4
结合两个文本文件之间添加一些分隔符?
cat file1 file2将合并两个文本文件。但是,如果要在两者之间添加一些分隔符,例如的一行或两行********************************,我是否必须打开第一个文件,并在其末尾添加该行,或者打开第二个文件,并在其顶部添加该行,然后运行该cat命令?只需运行命令就能完成吗?

2
UNIX中的工具减去文本文件?
我有一个大文件,由文本字段组成,这些文本字段以大表的形式用分号分隔。已排序。我有一个由相同文本字段组成的较小文件。在某个时候,有人将这个文件与其他文件串联在一起,然后进行了排序以形成上述的大文件。我想从大文件中减去小文件的行(即对于小文件中的每一行,如果大文件中存在匹配的字符串,则删除大文件中的该行)。 该文件大致如下所示 GenericClass1; 1; 2; NA; 3; 4; GenericClass1; 5; 6; NA; 7; 8; GenericClass2; 1; 5; NA; 3; 8; GenericClass2; 2; 6; NA; 4; 1; 等等 有没有快速的经典方法可以做到这一点,还是我必须使用awk?


8
在大文件中替换包含换行符的字符串
有谁知道基于非行的工具以某种内存有效的方式“二进制”搜索/替换字符串?也看到这个问题。 我有一个+ 2GB的文本文件,我想对其进行处理,类似于此操作: sed -e 's/>\n/>/g' 这意味着,我想删除a之后出现的所有换行符>,但不能在其他地方删除,以便排除tr -d。 此命令(我从类似问题的答案中得到)失败,并带有couldn't re-allocate memory: sed --unbuffered ':a;N;$!ba;s/>\n/>/g' 那么,还有其他方法不求助于C吗?我讨厌perl,但愿意在这种情况下例外:-) 我不确定数据中是否会出现任何字符,因此\n,如果可能的话,我想避免用另一个字符临时替换。 有什么好主意吗?

4
比较不同文件的两列并打印是否匹配
我正在使用Solaris 10,因此涉及-f的grep选项不起作用。 我有两个管道分隔的文件: 文件1: abc|123|BNY|apple| cab|234|cyx|orange| def|kumar|pki|bird| 文件2: abc|123| kumar|pki| cab|234 我想将file2的前两列与file1进行比较(在前两列中搜索file1的全部内容),如果它们匹配,则打印出file1的匹配行。然后搜索文件2的第二行,依此类推。 预期产量: abc|123|BNY|apple| cab|234|cyx|orange| 我的文件很大,包含大约40万行,因此我想加快执行速度。

2
在(包括)两个模式之间打印行
我想从行CK末的行开始grepping,而当行末的行停止grepping D。我尝试过grep "$CK" "$D" file..txt,但是没有用。 输入: kkkkkkkkkkk jjjjjjjjjjjjjjjjjj gggggggggggg/CK JHGHHHHHHHH HJKHKKLKLLL JNBHBHJKJJLKKL JLKKKLLKJLKJ/D GGGGGGGGGGGGGG GGGGGGGGGGGGGG 所需的输出: gggggggggggg/CK JHGHHHHHHHH HJKHKKLKLLL JNBHBHJKJJLKKL JLKKKLLKJLKJ/D

11
如何将一个文本文件拆分为多个文本文件?
我有一个名为entry.txt以下内容的文本文件: [ entry1 ] 1239 1240 1242 1391 1392 1394 1486 1487 1489 1600 1601 1603 1657 1658 1660 2075 2076 2078 2322 2323 2325 2740 2741 2743 3082 3083 3085 3291 3292 3294 3481 3482 3484 3633 3634 3636 3690 3691 3693 3766 3767 3769 4526 4527 4529 4583 …

1
如何删除大型的多GB文本文件中的重复行?
我的问题与此问题类似,但有两个不同的约束: 我有一个很大的\n定界词表-每行一个词。文件大小从2GB到最大10GB不等。 我需要删除所有重复的行。 该过程可以在删除重复项的过程中对列表进行排序,但不是必需的。 分区上有足够的空间来容纳输出的新的唯一单词列表。 我已经尝试了这两种方法,但是它们都因内存不足错误而失败。 sort -u wordlist.lst > wordlist_unique.lst awk '!seen[$0]++' wordlist.lst > wordlist_unique.lst awk: (FILENAME=wordlist.lst FNR=43601815) fatal: assoc_lookup: bucket-ahname_str: can't allocate 10 bytes of memory (Cannot allocate memory) 我还可以尝试其他哪些方法?

5
查找文件中任何位置包含多个关键字的文件
我正在寻找一种列出目录中所有文件的方法,该文件包含我要查找的关键字的完整集合,位于文件的任何位置。 因此,关键字不必出现在同一行上。 一种方法是: grep -l one $(grep -l two $(grep -l three *)) 三个关键字只是一个例子,也可以是两个或四个,依此类推。 我能想到的第二种方法是: grep -l one * | xargs grep -l two | xargs grep -l three 在另一个问题中出现的第三个方法是: find . -type f \ -exec grep -q one {} \; -a \ -exec grep -q two {} \; -a …

4
将命令的输出存储到环形缓冲区
我有一个长时间运行的命令,该命令在stdout上生成大量输出。例如,我希望仅保留最后三天或最后一个gibibyte(避免在中间使用切割线),并尽可能保留不超过20 MiB的文件块。每个文件块都以数字后缀或时间戳命名。 就像是: my-cmd | magic-command --output-file-template=my-cmd-%t \ --keep-bytes=1G \ --keep-time=3d \ --max-chunk-size=20M \ --compress=xz 会写: my-cmd-2014-09-05T10:04:23Z 当达到20M时,它将压缩并打开一个新文件,依此类推,过一会儿它将开始删除最旧的文件。 是否存在这样的命令? 我知道logrotate它管理其他应用程序编写的文件的能力,但是我正在寻找更简单的方法,而不必设置cron作业,指定规则,暂停进程等。




3
头吃多余的字符
预期以下shell命令仅输出输入流的奇数行: echo -e "aaa\nbbb\nccc\nddd\n" | (while true; do head -n 1; head -n 1 >/dev/null; done) 但是,它只是打印第一行:aaa。 与-c(--bytes)选项一起使用时不会发生相同的事情: echo 12345678901234567890 | (while true; do head -c 5; head -c 5 >/dev/null; done) 该命令1234512345按预期输出。但这仅在该实用程序的coreutils实现中有效head。该busybox的执行还是吃多余的字符,所以输出正好12345。 我想这种特定的实现方式是出于优化目的而完成的。您不知道行的结尾,因此不知道需要读取多少个字符。不消耗输入流中多余字符的唯一方法是逐字节读取流。但是一次从流中读取一个字节可能很慢。因此,我想head将输入流读取到足够大的缓冲区中,然后计算该缓冲区中的行数。 --bytes使用option 时无法说相同的话。在这种情况下,您知道需要读取多少个字节。因此,您可以准确地读取此字节数,但不能超过此数目。该corelibs实现使用这个机会,但是busybox的一个没有,它仍然比读取所需到缓冲区的字节以上。这样做可能是为了简化实现。 所以这个问题。head实用程序从输入流中消耗比要求更多的字符是否正确?Unix实用程序是否有某种标准?如果存在,是否指定了这种行为? 聚苯乙烯 您必须按Ctrl+C停止上面的命令。Unix实用程序不会在超越时失败EOF。如果您不想按,则可以使用更复杂的命令: echo 12345678901234567890 | (while true; do head -c 5; head -c …

5
合并大量文件
我有±10,000个文件(res.1- res.10000),它们全部由一列和相等数量的行组成。本质上,我想要的是简单;将所有文件按列合并到一个新文件中final.res。我尝试使用: paste res.* 但是(尽管这似乎对结果文件的一小部分有用,但是在整个集合上执行时会出现以下错误:Too many open files。 必须有一种“简便”的方法来完成此操作,但是不幸的是,我对UNIX还是很陌生。提前致谢! PS:让您大致了解一下(我的一个)数据文件: 0.5 0.5 0.03825 0.5 10211.0457 10227.8469 -5102.5228 0.0742 3.0944 ...

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.