How can I get the compressed file size of all the lines returned by zgrep on a .gz file? [on hold]











up vote
0
down vote

favorite












If I grep something on a text file then pipe to wc -c, I can see the size of all the lines returned in bytes. How can I get the compressed file size of all the lines returned by zgrep on a .gz file?



For example, I have a file named a.gz:



    zgrep abc a.gz | wc -c

    bytes of abc in gz, 395714


ll *.gz gives me:



    bytes of *.gz file, 113276


ll a (the uncompressed file) gives me:



    bytes of a, 1501625


How can I find the compressed size of all the lines returned by zgrep abc a.gz? I've tried to pipe to wc -c above and it gives me the uncompressed size (since 395714 is bigger than 113276).






linux grep gzip wc







share|improve this question















put on hold as unclear what you're asking by Jeff Schaller, JigglyNaga, Archemar, X Tian, thrig Nov 28 at 20:17


Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.











  • 1




    The size of those lines as compressed in the original file, or re-compressed?
    – Jeff Schaller
    Nov 28 at 1:38






  • 2




    I'm not sure, but I think gzip compresses data in blocks, not line-by-line. Also, zgrep's output is the decompressed string (abc in your example), not the compressed version.
    – Jeff Schaller
    Nov 28 at 1:49






  • 3




    Unless your original text is large enough to be a block size, I think it'll be compressed with data around it, potentially throwing off your calculations...?
    – Jeff Schaller
    Nov 28 at 1:51






  • 1




    That's a good point. It'll be hard to strip the data compressed around it. Also, the compressing algorithm might compress each of the same pattern differently depending on the data around it.
    – kouichi
    Nov 28 at 2:00






  • 1




    gzip doesn't know or care about lines. You can get a rough estimate of how much those lines add to the size by comparing the output of wc -c a.gz to zgrep -v pattern a.gz | gzip -c | wc -c. Notice the -v option to zgrep.
    – mosvy
    Nov 28 at 3:46

















up vote
0
down vote

favorite












If I grep something on a text file then pipe to wc -c, I can see the size of all the lines returned in bytes. How can I get the compressed file size of all the lines returned by zgrep on a .gz file?



For example, I have a file named a.gz:



    zgrep abc a.gz | wc -c

    bytes of abc in gz, 395714


ll *.gz gives me:



    bytes of *.gz file, 113276


ll a (the uncompressed file) gives me:



    bytes of a, 1501625


How can I find the compressed size of all the lines returned by zgrep abc a.gz? I've tried to pipe to wc -c above and it gives me the uncompressed size (since 395714 is bigger than 113276).






linux grep gzip wc







share|improve this question















put on hold as unclear what you're asking by Jeff Schaller, JigglyNaga, Archemar, X Tian, thrig Nov 28 at 20:17


Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.











  • 1




    The size of those lines as compressed in the original file, or re-compressed?
    – Jeff Schaller
    Nov 28 at 1:38






  • 2




    I'm not sure, but I think gzip compresses data in blocks, not line-by-line. Also, zgrep's output is the decompressed string (abc in your example), not the compressed version.
    – Jeff Schaller
    Nov 28 at 1:49






  • 3




    Unless your original text is large enough to be a block size, I think it'll be compressed with data around it, potentially throwing off your calculations...?
    – Jeff Schaller
    Nov 28 at 1:51






  • 1




    That's a good point. It'll be hard to strip the data compressed around it. Also, the compressing algorithm might compress each of the same pattern differently depending on the data around it.
    – kouichi
    Nov 28 at 2:00






  • 1




    gzip doesn't know or care about lines. You can get a rough estimate of how much those lines add to the size by comparing the output of wc -c a.gz to zgrep -v pattern a.gz | gzip -c | wc -c. Notice the -v option to zgrep.
    – mosvy
    Nov 28 at 3:46















up vote
0
down vote

favorite









up vote
0
down vote

favorite











If I grep something on a text file then pipe to wc -c, I can see the size of all the lines returned in bytes. How can I get the compressed file size of all the lines returned by zgrep on a .gz file?



For example, I have a file named a.gz:



    zgrep abc a.gz | wc -c

    bytes of abc in gz, 395714


ll *.gz gives me:



    bytes of *.gz file, 113276


ll a (the uncompressed file) gives me:



    bytes of a, 1501625


How can I find the compressed size of all the lines returned by zgrep abc a.gz? I've tried to pipe to wc -c above and it gives me the uncompressed size (since 395714 is bigger than 113276).






linux grep gzip wc







share|improve this question















If I grep something on a text file then pipe to wc -c, I can see the size of all the lines returned in bytes. How can I get the compressed file size of all the lines returned by zgrep on a .gz file?



For example, I have a file named a.gz:



    zgrep abc a.gz | wc -c

    bytes of abc in gz, 395714


ll *.gz gives me:



    bytes of *.gz file, 113276


ll a (the uncompressed file) gives me:



    bytes of a, 1501625


How can I find the compressed size of all the lines returned by zgrep abc a.gz? I've tried to pipe to wc -c above and it gives me the uncompressed size (since 395714 is bigger than 113276).






linux grep gzip wc




linux grep gzip wc






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 28 at 1:37









Jeff Schaller

37k1052121




37k1052121










asked Nov 28 at 1:24









kouichi

338




338




put on hold as unclear what you're asking by Jeff Schaller, JigglyNaga, Archemar, X Tian, thrig Nov 28 at 20:17


Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.






put on hold as unclear what you're asking by Jeff Schaller, JigglyNaga, Archemar, X Tian, thrig Nov 28 at 20:17


Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.










  • 1




    The size of those lines as compressed in the original file, or re-compressed?
    – Jeff Schaller
    Nov 28 at 1:38






  • 2




    I'm not sure, but I think gzip compresses data in blocks, not line-by-line. Also, zgrep's output is the decompressed string (abc in your example), not the compressed version.
    – Jeff Schaller
    Nov 28 at 1:49






  • 3




    Unless your original text is large enough to be a block size, I think it'll be compressed with data around it, potentially throwing off your calculations...?
    – Jeff Schaller
    Nov 28 at 1:51






  • 1




    That's a good point. It'll be hard to strip the data compressed around it. Also, the compressing algorithm might compress each of the same pattern differently depending on the data around it.
    – kouichi
    Nov 28 at 2:00






  • 1




    gzip doesn't know or care about lines. You can get a rough estimate of how much those lines add to the size by comparing the output of wc -c a.gz to zgrep -v pattern a.gz | gzip -c | wc -c. Notice the -v option to zgrep.
    – mosvy
    Nov 28 at 3:46
















  • 1




    The size of those lines as compressed in the original file, or re-compressed?
    – Jeff Schaller
    Nov 28 at 1:38






  • 2




    I'm not sure, but I think gzip compresses data in blocks, not line-by-line. Also, zgrep's output is the decompressed string (abc in your example), not the compressed version.
    – Jeff Schaller
    Nov 28 at 1:49






  • 3




    Unless your original text is large enough to be a block size, I think it'll be compressed with data around it, potentially throwing off your calculations...?
    – Jeff Schaller
    Nov 28 at 1:51






  • 1




    That's a good point. It'll be hard to strip the data compressed around it. Also, the compressing algorithm might compress each of the same pattern differently depending on the data around it.
    – kouichi
    Nov 28 at 2:00






  • 1




    gzip doesn't know or care about lines. You can get a rough estimate of how much those lines add to the size by comparing the output of wc -c a.gz to zgrep -v pattern a.gz | gzip -c | wc -c. Notice the -v option to zgrep.
    – mosvy
    Nov 28 at 3:46










1




1




The size of those lines as compressed in the original file, or re-compressed?
– Jeff Schaller
Nov 28 at 1:38




The size of those lines as compressed in the original file, or re-compressed?
– Jeff Schaller
Nov 28 at 1:38




2




2




I'm not sure, but I think gzip compresses data in blocks, not line-by-line. Also, zgrep's output is the decompressed string (abc in your example), not the compressed version.
– Jeff Schaller
Nov 28 at 1:49




I'm not sure, but I think gzip compresses data in blocks, not line-by-line. Also, zgrep's output is the decompressed string (abc in your example), not the compressed version.
– Jeff Schaller
Nov 28 at 1:49




3




3




Unless your original text is large enough to be a block size, I think it'll be compressed with data around it, potentially throwing off your calculations...?
– Jeff Schaller
Nov 28 at 1:51




Unless your original text is large enough to be a block size, I think it'll be compressed with data around it, potentially throwing off your calculations...?
– Jeff Schaller
Nov 28 at 1:51




1




1




That's a good point. It'll be hard to strip the data compressed around it. Also, the compressing algorithm might compress each of the same pattern differently depending on the data around it.
– kouichi
Nov 28 at 2:00




That's a good point. It'll be hard to strip the data compressed around it. Also, the compressing algorithm might compress each of the same pattern differently depending on the data around it.
– kouichi
Nov 28 at 2:00




1




1




gzip doesn't know or care about lines. You can get a rough estimate of how much those lines add to the size by comparing the output of wc -c a.gz to zgrep -v pattern a.gz | gzip -c | wc -c. Notice the -v option to zgrep.
– mosvy
Nov 28 at 3:46






gzip doesn't know or care about lines. You can get a rough estimate of how much those lines add to the size by comparing the output of wc -c a.gz to zgrep -v pattern a.gz | gzip -c | wc -c. Notice the -v option to zgrep.
– mosvy
Nov 28 at 3:46

















active

oldest

votes






















active

oldest

votes













active

oldest

votes









active

oldest

votes






active

oldest

votes

-

Popular posts from this blog

サソリ

Image
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。 （ 2019年1月 ） 「 サソリ 」のその他の用法については「サソリ (曖昧さ回避)」をご覧ください。 「 スコーピオン 」と「 スコルピオン 」はこの項目へ転送されています。その他の用法については「スコーピオン」をご覧ください。 サソリ目 生息年代: 430–0 Ma PreЄ Є O S D C P T J K Pg N シルル紀前期-現世 ダイオウサソリ（ Pandinus Imperator ） 分類 界 : 動物界 Animalia 門 : 節足動物門 Arthropoda 亜門 : 鋏角亜門 Chelicerata 綱 : クモガタ綱 Arachnida 目 : サソリ目 Scorpiones 学名 Scorpiones C. L. Koch, 1837 英名 Scorpion 上科 Pseudochactoidea キョクトウサソリ上科 Buthoidea Chaeriloidea Chactoidea Iuroidea Scorpionoidea サソリ （ サソリ類 、 蠍 、 蝎 、 scorpion ）は、鋏角亜門・クモガタ綱の サソリ目 （ Scorpiones ）に属する節足動物の総称である。体の前端に鋏型の触肢、後端に毒針を有する捕食者である。 1700種以上を含め、最古の化石記録は4億3千万年前のシルル紀まで遡る。有毒生物として広く知られるが、人間の命にかかわる毒を持つものはごく一部の種類に過ぎない。 目次 1 形態 1.1 前体 1.2 後体 1.2.1 中体 1.2.2 終体 2 雌雄 3 生態 3.1 天敵 3.2 生殖 4 分布 5 毒 6 蛍光現象 7 分類
Read more

広島県道265号伴広島線

Image
一般県道 広島県道265号伴広島線 路線延長 km 起点 広島県広島市安佐南区伴東7丁目 終点 広島県広島市中区榎町 接続する 主な道路 （記法） 広島県道38号広島豊平線 広島県道71号広島湯来線 山陽自動車道五日市IC 国道183号（ 国道261号重複） ■テンプレート（■ノート ■使い方） ■PJ道路 広島県道265号伴広島線 （ひろしまけんどう265ごう ともひろしません）は広島県広島市安佐南区から広島県広島市中区を結ぶ一般県道である。 目次 1 路線データ 2 通過する自治体 3 見どころ 4 接続道路 4.1 本線 4.2 旧道 5 別名 6 関連項目 路線データ 本線 起点：広島市安佐南区伴東7丁目・大原下橋南詰交差点（広島県道38号広島豊平線（本線・旧道）交点） 終点：広島市中区榎町・十日市交差点（国道183号（国道261号重用）交点） 総延長： 旧道 起点：広島市安佐南区伴東4丁目・新細坂交差点（広島県道38号広島豊平線交点） 終点：広島市安佐南区伴中央4丁目・寺組橋(南)交差点（広島県道265号伴広島線（本線）交点） 総延長： 通過する自治体 広島県 広島市（安佐南区、佐伯区、西区、中区） 見どころ 広島高速交通広島新交通1号線（アストラムライン） 広島広域公園 広島広域公園陸上競技場（広島ビッグアーチ） 己斐峠 己斐橋（太田川放水路） 天満橋（天満川） 接続道路 本線 広島県道38号広島豊平線（本線・旧道）（広島市安佐南区伴東7丁目・大原下橋南詰交差点〔起点〕） 広島県道71号広島湯来線（本線）（広島市安佐南区伴中央2丁目・伴交番入口交差点 - 広島市安佐南区伴中央4丁目・寺組橋(南)交差点間で重用） 広島県道71号広島湯来線（旧道）（広島県道265号伴広島線（旧道）重用）（広島市安佐南区伴中央4丁目・寺組橋(南)交差点） 広島県道71号広島湯来線（広島市安佐南区伴中央4丁目・寺組橋(南)交差点 - 広島市佐伯区五日市町石内・五月が丘(南)交差点間で重用）
Read more

Setup Asymptote in Texstudio

Image
0 Good time of the day! I am trying to compile the following file: documentclass[12pt]{article} usepackage[inline]{asymptote} begin{document} Here is a venn diagram produced with Asymptote, drawn to width 4cm: defA{A} defB{V{B}} begin{figure} begin{center} begin{asy} size(4cm,0); pen colour1=red; pen colour2=green; pair z0=(0,0); pair z1=(-1,0); pair z2=(1,0); real r=1.5; path c1=circle(z1,r); path c2=circle(z2,r); fill(c1,colour1); fill(c2,colour2); picture intersection=new picture; fill(intersection,c1,colour1+colour2); clip(intersection,c2); add(intersection); draw(c1); draw(c2); //draw("$A$",box,z1)
Read more