Answers.Body: <p>You can trivially do this with standard *nix tools. Here are a few options:</p>
  <pre><code>sed -n 's/^&gt;//p' file.fa 
  awk 'sub(/^&gt;/,&quot;&quot;)' file.fa
  grep '^&gt;' file.fa | tr -d '&gt;'
  perl -ne 'print if s/^&gt;//' file.fa 
  </code></pre>
  <p>The advantage of these is that they will work on any POSIX-compliant system and most other *nix flavors, even if they're not POSIX such as Linux, out of the box without needing to install any external tools.</p>
  <p>Another thing to take into account is how fast a command is, especially when dealing with large files. I ran a few tests using the solutions presented here on the human hg38 genome assembly which can be downloaded <a href="https://ftp.ncbi.nlm.nih.gov/genomes/all/GCA/000/001/405/GCA_000001405.15_GRCh38/GO_TO_CURRENT_VERSION/GCA_000001405.29_GRCh38.p14_genomic.fna.gz" rel="nofollow noreferrer">here</a> and <code>seqkit</code> version <code>2.2.0</code> which was downloaded from <a href="https://github.com/shenwei356/seqkit/releases/download/v2.2.0/seqkit_linux_amd64.tar.gz" rel="nofollow noreferrer">here</a>. The file was stored locally on my laptop's SSD drive, and the laptop itself is:</p>
  <pre class="lang-sh prettyprint-override"><code>$ inxi 
  CPU: quad core Intel Core i7-6820HQ (-MT MCP-)
  speed/min/max: 2896/800/3600 MHz Kernel: 5.17.5-arch1-1 x86_64
  Up: 25d 10h 27m Mem: 15035.9/31958.1 MiB (47.0%)
  Storage: 476.94 GiB (103.1% used) Procs: 452 Shell: Bash inxi: 3.3.15
  </code></pre>
  <p>To get more accurate results, I used a little function I have which will run the command you give it a specified number of times and then report the average <em>real</em> time across all runs. Here's the code if you want to try it:</p>
  <pre class="lang-sh prettyprint-override"><code>timethis(){
      max=$1;
      shift;
  
      for com
      do
          printf '\nCOMMAND: %s\n' &quot;<span class="math-container">$com"
      c=0;
      while [[ $</span>c -lt <span class="math-container">$max ]]
      do
        let c++;
        ( time -p eval "$</span>com&quot; ) 2&gt;&amp;1 | grep -oP 'real.*?\K[\d\.]+'
          done | 
          awk -vm=<span class="math-container">$max '{k+=$</span>1}END{print (k/m)}';
      done
  }
  </code></pre>
  <p>And the results. These are the average &quot;real&quot; (i.e. wall clock) times taken across 10 runs:</p>
  <pre><code><span class="math-container">$ timethis 10 \
    "rg '^&gt;' GCA_000001405.29_GRCh38.p14_genomic.fna | tr -d '&gt;' &gt;/dev/null" \
    "grep '^&gt;' GCA_000001405.29_GRCh38.p14_genomic.fna | tr -d '&gt;' &gt;/dev/null" \
    "sed -n 's/^&gt;//p' GCA_000001405.29_GRCh38.p14_genomic.fna &gt;/dev/null" \
    "perl -ne 'print if s/^&gt;//' GCA_000001405.29_GRCh38.p14_genomic.fna &gt;/dev/null" \
    "./seqkit seq -n GCA_000001405.29_GRCh38.p14_genomic.fna &gt;/dev/null" \
    "awk 'sub(/^&gt;/,\"\")' GCA_000001405.29_GRCh38.p14_genomic.fna &gt;/dev/null" \
    "perl -nle 'push @res, $</span>_  while s/^&gt;//; END {print  join \&quot;\n\&quot;,@res}' GCA_000001405.29_GRCh38.p14_genomic.fna&quot;
  
  COMMAND: rg '^&gt;' GCA_000001405.29_GRCh38.p14_genomic.fna | tr -d '&gt;' &gt;/dev/null
  0.474
  
  COMMAND: grep '^&gt;' GCA_000001405.29_GRCh38.p14_genomic.fna | tr -d '&gt;' &gt;/dev/null 
  0.583
  
  COMMAND: sed -n 's/^&gt;//p' GCA_000001405.29_GRCh38.p14_genomic.fna &gt;/dev/null 
  5.62
  
  COMMAND: perl -ne 'print if s/^&gt;//' GCA_000001405.29_GRCh38.p14_genomic.fna  &gt;/dev/null 
  6.408
  
  COMMAND: ./seqkit seq -n GCA_000001405.29_GRCh38.p14_genomic.fna &gt;/dev/null 
  4.326
  
  COMMAND: awk 'sub(/^&gt;/,&quot;&quot;)' GCA_000001405.29_GRCh38.p14_genomic.fna &gt;/dev/null 
  13.518
  
  COMMAND: perl -nle 'push @res, 3  while s/^&gt;//; END {print  join &quot;\n&quot;,@res}' GCA_000001405.29_GRCh38.p14_genomic.fna 
  8.455
  </code></pre>
  <p>As you can see above, the <code>grep</code> or <code>rg</code> and <code>tr</code> approaches only took around half a second on average, so that is clearly much faster than any of the other choices. However, <code>seqkit</code> is pretty good since it only took around 4 seconds, faster than any of the other ad hoc solutions.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-05-30T20:08:11.680Z
Answers.Text: Seqkit is arguably a bioinfo standard tool ;)
Answers.UserDisplayName: Cornelius Roemer
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-05-31T08:34:55.040Z
Answers.Text: @CorneliusRoemer I guess. I have never used it myself and have been doing bioinformatics for more than 20 years. But by "standard" I mean "standard *nix tools", not bioinformatics tools. I edited to clarify.
Answers.UserDisplayName: terdon
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-05-31T14:17:50.443Z
Answers.Text: @CorneliusRoemer there are weakness on reliance on a developers 'kit'. Flexibility, if you wanted to count the number of pangotype A.1 in SARS-CoV-2, my code is easy to modify to />.*A\.1.*/ and introduce $count++ , whereas you would need to search seqkit to see if the developer had foresight. Bugs: are 'kits' completely bug free, how can you be sure? Upgrades: the promised upgrade ain't ever released (very, very common). Distributing your algorithm: this is a headache because you've now got a dependency which you don't have permission to redistribute.
Answers.UserDisplayName: M__
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-05-31T14:34:58.767Z
Answers.Text: @M__ of course there are use cases for *nix tools. But there are also use cases for *kits. In this case I wanted to use a memorable solution that will not require lookup every time. The two other answers are arguably off topic because they don't address the question - which explicitly asked for `seqkit` usage. Another *kit would have been more on-topic than *nix tools. I don't mind them, it's just a bit typical for SO, you ask a question and you get a solution that's for a different question ;)
Answers.UserDisplayName: Cornelius Roemer
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-05-31T14:51:05.033Z
Answers.Text: @CorneliusRoemer answers providing different approaches are welcome across the Stack Exchange network (note that this site is _not_ [SO]). Especially when there is already a fine answer with using the requested tool. As for what is memorable, that is entirely personal. You are familiar with `seqt` so that seems easy and memorable for you. I have been using *nix tools for 20 years, so nothing is more memorable than a simple `sed s/foo/bar/`. But that's fine! That's the beauty of it: we can all provide answers and people can choose whichever approach works well for them. Everybody wins!
Answers.UserDisplayName: terdon
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-05-31T15:03:18.300Z
Answers.Text: Fair :) though it's `seqkit` not `seqt`
Answers.UserDisplayName: Cornelius Roemer
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-05-31T15:05:53.170Z
Answers.Text: Heh, you see how memorable I find it, @CorneliusRoemer! :P
Answers.UserDisplayName: terdon
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-05-31T17:42:10.347Z
Answers.Text: @CorneliusRoemer you've got to agree with terdon: seqkit is far too slow. It is worrying. This would cause problems on the data sets in question where a million strong fasta file is normal. Take your pick but realistically its the end of this discussion, there's no point using an inefficient algorithm against huge data sets, sooner or later they'll be a RAM issue.
Answers.UserDisplayName: M__
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-05-31T18:10:13.613Z
Answers.Text: That's a good reason to use an alternative tool, I agree, if speed matters. If you use the command line interactively though, terseness can be more important. It depends on the use case I suppose. I'd be curious how fast `rg` would be. The slowdown in `seqkit` seems to be related to file access? Large `sys` time.
  Can you add a link on how to download the benchmark data so I can compare on my machine and try `rg`?
Answers.UserDisplayName: Cornelius Roemer
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-05-31T18:34:24.573Z
Answers.Text: @CorneliusRoemer good catch! The test results I show were using a genome file stored on a network drive, which would of course affect the times. I had assumed that wouldn't be relevant since all tools were accessing the same file over the same network. However, I downloaded a different genome file locally and on my local SSD, `seqkit` is far more competitive. I'll update in a few minutes with the new test results, but do you have any idea why one tool would be affected by the network I/O times more than another? That's very surprising to me.
Answers.UserDisplayName: terdon
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-05-31T18:50:52.720Z
Answers.Text: Ah interesting! I thought you were the bioinformatician with 20y of experience. I barely have 1 :D
  Seqkit could read in chunks? No idea, one should maybe even open this as a bug on Github. By the way there are other similar tools out there.
  Please try `rg` too, it's a Rust port of grep and likely faster than grep. Also best to link to the data file so it's reproducible. Performance could differ on macOS and *nix. Ah yes, that's an advantage of `seqkit` it could possibly work even on windows...
Answers.UserDisplayName: Cornelius Roemer
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-05-31T18:54:31.147Z
Answers.Text: @CorneliusRoemer Ha! Serves me right for throwing my age around :) I do indeed have 20 years of experience, but I still come from the world of biology, not programming so there will be holes in my knowledge. I have updated the post with the new results, including all data needed to reproduce them, and `seqkit` now only loses out to `grep` + `tr` but is faster than all the others. So much for my years of experience, I have to eat my words now!
Answers.UserDisplayName: terdon
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-05-31T18:55:28.633Z
Answers.Text: @M__ my initial numbers don't hold up when doing the same thing with a fasta file stored on a local SSD. So it looks like `seqkit` is slower than expected when reading data over a network but is faster than everything except the simple `grep` + `tr` when running on a local file.
Answers.UserDisplayName: terdon
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-05-31T22:08:23.483Z
Answers.Text: @CorneliusRoemer if it is chunking it at source, its not a bug. It would make sense. Does it parallelise? Chunking and parallelising would be a technique to speed the operation and minimise RAM issues. Obviously it will fall over via a network.
Answers.UserDisplayName: M__
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-05-31T22:41:20.493Z
Answers.Text: Thanks @terdon its surely grep/ripgrep. If `seqkit` is chunking at source, that is really interesting (its clearly not pulling the whole file in and then chunking).
Answers.UserDisplayName: M__
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-05-30T17:49:16.827Z
Answers.LastActivityDate: 2022-05-31T19:04:43.280Z
Answers.LastEditDate: 2022-05-31T19:04:43.280Z
Answers.UserDisplayName: terdon
Answers.Body: <p>The nice thing about <code>seqkit</code> is that the answer is really simple and memorable:</p>
  <pre class="lang-bash prettyprint-override"><code>seqkit seq -n sequences.fasta
  </code></pre>
  <p>This will output a text file containing one sequence name per line:</p>
  <pre><code>MPX/PT0001/2022
  MPX/PT0002/2022
  MPX/PT0003/2022
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-05-30T12:02:50.653Z
Answers.Text: Thanks for posting back @CorneliusRoemer thats useful.
Answers.UserDisplayName: M__
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-05-30T09:04:31.710Z
Answers.LastActivityDate: 2022-05-30T09:04:31.710Z
Answers.UserDisplayName: Cornelius Roemer
Answers.Body: <p>Or a bit more verbose ...</p>
  <pre><code>perl -nle 'push @res, $_  while s/^&gt;//; END {print  join &quot;\n&quot;,@res}' myfile.fa
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-05-30T19:35:52.140Z
Answers.LastActivityDate: 2022-05-30T19:38:56.090Z
Answers.LastEditDate: 2022-05-30T19:38:56.090Z
Answers.UserDisplayName: M__
Body: <p>FASTA files can be very big and unwieldy, especially if lines are at most 80 characters, one can't speed up browsing them by using <code>less</code> with <code>-S</code> to have one sequence every two lines.</p>
  <p>How can I extract just the strain names (or sequence names, i.e. the string on the line starting with <code>&gt;</code>) into a list? I'd like to use <code>seqkit</code> since I'm already familiar with it and know some of the flags and idioms it uses.</p>
  <p>I googled the question but couldn't find an answer using seqkit - the examples all use <code>awk</code>, <code>grep</code>, <code>sed</code> or similar, which are alright for copy/pasting but not very memorable.</p>
  
Tags: <phylogenetics><fasta><identifiers><multi-fasta><seqkit>
Title: How to get strain names/ids contained in a multi FASTA file using seqkit?
ThreadText: # How to get strain names/ids contained in a multi FASTA file using seqkit?
  
  (Asked by: username_0 on 2022-05-30)
  
  FASTA files can be very big and unwieldy, especially if lines are at most 80 characters, one can't speed up browsing them by using `less` with `-S` to have one sequence every two lines.
  
  How can I extract just the strain names (or sequence names, i.e. the string on the line starting with `>`) into a list? I'd like to use `seqkit` since I'm already familiar with it and know some of the flags and idioms it uses.
  
  I googled the question but couldn't find an answer using seqkit - the examples all use `awk`, `grep`, `sed` or similar, which are alright for copy/pasting but not very memorable.
  
  **Tags:** phylogenetics, fasta, identifiers, multi-fasta, seqkit
  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_0 on 2022-05-30. Score: 7
  
  The nice thing about `seqkit` is that the answer is really simple and memorable:
  
  ```bash
  seqkit seq -n sequences.fasta
  
  ```
  
  This will output a text file containing one sequence name per line:
  
  ```
  MPX/PT0001/2022
  MPX/PT0002/2022
  MPX/PT0003/2022
  
  ```
  
  > **Comments:**
  > **username_2**: Thanks for posting back @username_0 thats useful.  
  
  ---
  
  ### Answer by username_1 on 2022-05-30. Score: 5
  
  You can trivially do this with standard \*nix tools. Here are a few options:
  
  ```
  sed -n 's/^>//p' file.fa 
  awk 'sub(/^>/,"")' file.fa
  grep '^>' file.fa | tr -d '>'
  perl -ne 'print if s/^>//' file.fa 
  
  ```
  
  The advantage of these is that they will work on any POSIX-compliant system and most other \*nix flavors, even if they're not POSIX such as Linux, out of the box without needing to install any external tools.
  
  Another thing to take into account is how fast a command is, especially when dealing with large files. I ran a few tests using the solutions presented here on the human hg38 genome assembly which can be downloaded [here](https://ftp.ncbi.nlm.nih.gov/genomes/all/GCA/000/001/405/GCA_000001405.15_GRCh38/GO_TO_CURRENT_VERSION/GCA_000001405.29_GRCh38.p14_genomic.fna.gz) and `seqkit` version `2.2.0` which was downloaded from [here](https://github.com/shenwei356/seqkit/releases/download/v2.2.0/seqkit_linux_amd64.tar.gz). The file was stored locally on my laptop's SSD drive, and the laptop itself is:
  
  ```sh
  $ inxi 
  CPU: quad core Intel Core i7-6820HQ (-MT MCP-)
  speed/min/max: 2896/800/3600 MHz Kernel: 5.17.5-arch1-1 x86_64
  Up: 25d 10h 27m Mem: 15035.9/31958.1 MiB (47.0%)
  Storage: 476.94 GiB (103.1% used) Procs: 452 Shell: Bash inxi: 3.3.15
  
  ```
  
  To get more accurate results, I used a little function I have which will run the command you give it a specified number of times and then report the average *real* time across all runs. Here's the code if you want to try it:
  
  ```sh
  timethis(){
      max=$1;
      shift;
  
      for com
      do
          printf '\nCOMMAND: %s\n' "$com"
      c=0;
      while [[ $c -lt $max ]]
      do
        let c++;
        ( time -p eval "$com" ) 2>&1 | grep -oP 'real.*?\K[\d\.]+'
          done | 
          awk -vm=$max '{k+=$1}END{print (k/m)}';
      done
  }
  
  ```
  
  And the results. These are the average "real" (i.e. wall clock) times taken across 10 runs:
  
  ```
  $ timethis 10 \
    "rg '^>' GCA_000001405.29_GRCh38.p14_genomic.fna | tr -d '>' >/dev/null" \
    "grep '^>' GCA_000001405.29_GRCh38.p14_genomic.fna | tr -d '>' >/dev/null" \
    "sed -n 's/^>//p' GCA_000001405.29_GRCh38.p14_genomic.fna >/dev/null" \
    "perl -ne 'print if s/^>//' GCA_000001405.29_GRCh38.p14_genomic.fna >/dev/null" \
    "./seqkit seq -n GCA_000001405.29_GRCh38.p14_genomic.fna >/dev/null" \
    "awk 'sub(/^>/,\"\")' GCA_000001405.29_GRCh38.p14_genomic.fna >/dev/null" \
    "perl -nle 'push @res, $_  while s/^>//; END {print  join \"\n\",@res}' GCA_000001405.29_GRCh38.p14_genomic.fna"
  
  COMMAND: rg '^>' GCA_000001405.29_GRCh38.p14_genomic.fna | tr -d '>' >/dev/null
  0.474
  
  COMMAND: grep '^>' GCA_000001405.29_GRCh38.p14_genomic.fna | tr -d '>' >/dev/null 
  0.583
  
  COMMAND: sed -n 's/^>//p' GCA_000001405.29_GRCh38.p14_genomic.fna >/dev/null 
  5.62
  
  COMMAND: perl -ne 'print if s/^>//' GCA_000001405.29_GRCh38.p14_genomic.fna  >/dev/null 
  6.408
  
  COMMAND: ./seqkit seq -n GCA_000001405.29_GRCh38.p14_genomic.fna >/dev/null 
  4.326
  
  COMMAND: awk 'sub(/^>/,"")' GCA_000001405.29_GRCh38.p14_genomic.fna >/dev/null 
  13.518
  
  COMMAND: perl -nle 'push @res, 3  while s/^>//; END {print  join "\n",@res}' GCA_000001405.29_GRCh38.p14_genomic.fna 
  8.455
  
  ```
  
  As you can see above, the `grep` or `rg` and `tr` approaches only took around half a second on average, so that is clearly much faster than any of the other choices. However, `seqkit` is pretty good since it only took around 4 seconds, faster than any of the other ad hoc solutions.
  
  > **Comments:**
  > **username_0**: Seqkit is arguably a bioinfo standard tool ;)  
  > **username_1**: @username_0 I guess. I have never used it myself and have been doing bioinformatics for more than 20 years. But by "standard" I mean "standard *nix tools", not bioinformatics tools. I edited to clarify.  
  > **username_2**: @username_0 there are weakness on reliance on a developers 'kit'. Flexibility, if you wanted to count the number of pangotype A.1 in SARS-CoV-2, my code is easy to modify to />.*A\.1.*/ and introduce $count++ , whereas you would need to search seqkit to see if the developer had foresight. Bugs: are 'kits' completely bug free, how can you be sure? Upgrades: the promised upgrade ain't ever released (very, very common). Distributing your algorithm: this is a headache because you've now got a dependency which you don't have permission to redistribute.  
  > **username_0**: @username_2 of course there are use cases for *nix tools. But there are also use cases for *kits. In this case I wanted to use a memorable solution that will not require lookup every time. The two other answers are arguably off topic because they don't address the question - which explicitly asked for `seqkit` usage. Another *kit would have been more on-topic than *nix tools. I don't mind them, it's just a bit typical for SO, you ask a question and you get a solution that's for a different question ;)  
  > **username_1**: @username_0 answers providing different approaches are welcome across the Stack Exchange network (note that this site is _not_ [SO]). Especially when there is already a fine answer with using the requested tool. As for what is memorable, that is entirely personal. You are familiar with `seqt` so that seems easy and memorable for you. I have been using *nix tools for 20 years, so nothing is more memorable than a simple `sed s/foo/bar/`. But that's fine! That's the beauty of it: we can all provide answers and people can choose whichever approach works well for them. Everybody wins!  
  > **username_0**: Fair :) though it's `seqkit` not `seqt`  
  > **username_1**: Heh, you see how memorable I find it, @username_0! :P  
  > **username_2**: @username_0 you've got to agree with username_1: seqkit is far too slow. It is worrying. This would cause problems on the data sets in question where a million strong fasta file is normal. Take your pick but realistically its the end of this discussion, there's no point using an inefficient algorithm against huge data sets, sooner or later they'll be a RAM issue.  
  > **username_0**: That's a good reason to use an alternative tool, I agree, if speed matters. If you use the command line interactively though, terseness can be more important. It depends on the use case I suppose. I'd be curious how fast `rg` would be. The slowdown in `seqkit` seems to be related to file access? Large `sys` time. Can you add a link on how to download the benchmark data so I can compare on my machine and try `rg`?  
  > **username_1**: @username_0 good catch! The test results I show were using a genome file stored on a network drive, which would of course affect the times. I had assumed that wouldn't be relevant since all tools were accessing the same file over the same network. However, I downloaded a different genome file locally and on my local SSD, `seqkit` is far more competitive. I'll update in a few minutes with the new test results, but do you have any idea why one tool would be affected by the network I/O times more than another? That's very surprising to me.  
  > **username_0**: Ah interesting! I thought you were the bioinformatician with 20y of experience. I barely have 1 :D Seqkit could read in chunks? No idea, one should maybe even open this as a bug on Github. By the way there are other similar tools out there. Please try `rg` too, it's a Rust port of grep and likely faster than grep. Also best to link to the data file so it's reproducible. Performance could differ on macOS and *nix. Ah yes, that's an advantage of `seqkit` it could possibly work even on windows...  
  > **username_1**: @username_0 Ha! Serves me right for throwing my age around :) I do indeed have 20 years of experience, but I still come from the world of biology, not programming so there will be holes in my knowledge. I have updated the post with the new results, including all data needed to reproduce them, and `seqkit` now only loses out to `grep` + `tr` but is faster than all the others. So much for my years of experience, I have to eat my words now!  
  > **username_1**: @username_2 my initial numbers don't hold up when doing the same thing with a fasta file stored on a local SSD. So it looks like `seqkit` is slower than expected when reading data over a network but is faster than everything except the simple `grep` + `tr` when running on a local file.  
  > **username_2**: @username_0 if it is chunking it at source, its not a bug. It would make sense. Does it parallelise? Chunking and parallelising would be a technique to speed the operation and minimise RAM issues. Obviously it will fall over via a network.  
  > **username_2**: Thanks @username_1 its surely grep/ripgrep. If `seqkit` is chunking at source, that is really interesting (its clearly not pulling the whole file in and then chunking).  
  
  ---
  
  ### Answer by username_2 on 2022-05-30. Score: 1
  
  Or a bit more verbose ...
  
  ```
  perl -nle 'push @res, $_  while s/^>//; END {print  join "\n",@res}' myfile.fa
  
  ```
  
  
  ---
  
  