I'm trying to make a shell script, I want to cut a string using the 'cut' unix command, as follows:

namecmpaux=$(echo $namecmp |cut -c0-19)

But when I run the shell tells me the following error:

cut: fields and positions are numbered from 1 
Try `cut - help 'for more information.

I remember previously used the 'cut' command using zero as the lower limit position, but now tells me that the command should start at 1. Why?, depends on the operating system? previously used SunOS and now i'm using ubuntu 12.04

  • 2
    Hmm, I don't see anything about field 0 in the cut man page on a solaris 8 system, but 0 works as the start of a range. The man page for GNU cut (i.e. linux) is quite clear that fields start with 1. Looks like you were relying on undocumented behaviour on SunOS. Mar 27, 2014 at 19:53

3 Answers 3


No, it's the same in every cut implementation. Numbers start at one, it's just the Solaris' one will not complain if you provide 0 and will treat it as 1. Both 0 and 1 there means the first character, and 2 means the second character:

$ echo test | cut -c 0-2
$ echo test | cut -c 1-2

busybox cut or the cut builtin in ksh93 also don't complain. GNU cut just tries to be helpful in telling you that you probably don't have the right idea about what's the first index.

A real difference though is that GNU and busybox cut (at least as of 2014-03-27), count in bytes for -c, while Solaris or ksh cut count in characters (as POSIX requires).

$ echo 'Stéphane' | cut -c 1-4
$ echo 'Stéphane' | busybox cut -c 1-4
$ echo 'Stéphane' | ksh -c 'command /opt/ast/bin/cut -c 1-4'

(in a UTF-8 locale, é (U+00E9) takes 2 bytes)


Yes, that might indeed be OS-dependent (or rather dependent on who wrote your version of cut).

If you take a look at man cut, you will see that cut from GNU's coreutils counts bytes, characters and fields from 1:

Use one, and only one of -b, -c or -f. [...] Each range is one of:
      N      N'th byte, character or field, counted from 1

Again, this might differ on a different system if its maintainers have decided to use an implementation of cut other than the GNU one, so better be safe and take a look at the manpage to be sure.


It even worked before on Linux. I was just bitten by it (On Debian, after an update to the coreutils package which contains the cut command) and found this bug.

It's a bug in coreutils:


Someone broke the backward compatibility on purpose and nobody fixed it. It used to be like that 0 was okay, too and treated as 1. Now 0 produces an error. So all scripts which depend on this behaviour are broken and must be changed.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .