3 replaced http://unix.stackexchange.com/ with https://unix.stackexchange.com/
source | link

This is a long-standing bug in bash's alias expansion. I could reproduce it on Debian lenny amd64 with bash 3.2.29(1), Debian squeeze i386 with 4.1.5(1), and Windows XP with Cygwin 1.7.7-1 with bash 4.1.9(3).

A few experiments show that the bug is very sensitive to variations in how the alias is used. hgfoo or hgfoo : exhibits the bug, but { hgfoo :; } and (hgfoo) work fine. Using a function instead of an alias also works.

I investigated a bit, trying to extract a smaller example. The weirdness seems to stem from having a newline in the alias. Here is a simple example where bash (3.2.29 or 4.1.9) misbehaves. This alias works as expected (from my reading of Single Unix v3) under pdksh, ksh93, ash and zsh under Debian lenny, namely oops prints foo bar.

$ alias oops='a=$(echo bar)
> echo foo $a'
$ oops
foo foo echo bar

The bug may be related to a reported bug about “strange delayed aliases”, but that discussion focuses on line continuations (backslash-newline) which is not used here.


In any case, use a function! Aliases are for one-liners where you're just specifying some default options for a command. A function would have the additional benefit that you could pass arguments to hg:

hgfoo () {
  localChanges=$(hg st -m "$@")
  …
}

¹ I initially thought this was a Cygwin bug, but as ak2ak2 pointed out, this bug occurs under Linux as well.

This is a long-standing bug in bash's alias expansion. I could reproduce it on Debian lenny amd64 with bash 3.2.29(1), Debian squeeze i386 with 4.1.5(1), and Windows XP with Cygwin 1.7.7-1 with bash 4.1.9(3).

A few experiments show that the bug is very sensitive to variations in how the alias is used. hgfoo or hgfoo : exhibits the bug, but { hgfoo :; } and (hgfoo) work fine. Using a function instead of an alias also works.

I investigated a bit, trying to extract a smaller example. The weirdness seems to stem from having a newline in the alias. Here is a simple example where bash (3.2.29 or 4.1.9) misbehaves. This alias works as expected (from my reading of Single Unix v3) under pdksh, ksh93, ash and zsh under Debian lenny, namely oops prints foo bar.

$ alias oops='a=$(echo bar)
> echo foo $a'
$ oops
foo foo echo bar

The bug may be related to a reported bug about “strange delayed aliases”, but that discussion focuses on line continuations (backslash-newline) which is not used here.


In any case, use a function! Aliases are for one-liners where you're just specifying some default options for a command. A function would have the additional benefit that you could pass arguments to hg:

hgfoo () {
  localChanges=$(hg st -m "$@")
  …
}

¹ I initially thought this was a Cygwin bug, but as ak2 pointed out, this bug occurs under Linux as well.

This is a long-standing bug in bash's alias expansion. I could reproduce it on Debian lenny amd64 with bash 3.2.29(1), Debian squeeze i386 with 4.1.5(1), and Windows XP with Cygwin 1.7.7-1 with bash 4.1.9(3).

A few experiments show that the bug is very sensitive to variations in how the alias is used. hgfoo or hgfoo : exhibits the bug, but { hgfoo :; } and (hgfoo) work fine. Using a function instead of an alias also works.

I investigated a bit, trying to extract a smaller example. The weirdness seems to stem from having a newline in the alias. Here is a simple example where bash (3.2.29 or 4.1.9) misbehaves. This alias works as expected (from my reading of Single Unix v3) under pdksh, ksh93, ash and zsh under Debian lenny, namely oops prints foo bar.

$ alias oops='a=$(echo bar)
> echo foo $a'
$ oops
foo foo echo bar

The bug may be related to a reported bug about “strange delayed aliases”, but that discussion focuses on line continuations (backslash-newline) which is not used here.


In any case, use a function! Aliases are for one-liners where you're just specifying some default options for a command. A function would have the additional benefit that you could pass arguments to hg:

hgfoo () {
  localChanges=$(hg st -m "$@")
  …
}

¹ I initially thought this was a Cygwin bug, but as ak2 pointed out, this bug occurs under Linux as well.

2 the bug is actually not specific to Windows, thanks to ak2 for pointing this out; extracted a small example
source | link

This is a long-standing bug either in the Cygwin port of bash or in the Cygwin librariesbash's alias expansion. I could reproduce it on aDebian lenny amd64 with bash 3.2.29(1), Debian squeeze i386 with 4.1.5(1), and Windows XP machine runningwith Cygwin 1.7.7-1 with bash 4.1.9(3).

It looks like some of the code is executed both in the parent process and in the child process after a fork. Implementing fork (a fundamental unix concept) on OSes that don't have it (such as Windows) is difficult, especially if you want the implementation to be reasonably efficient. So I'm not altogether surprised to see a bug there.

A few experiments show that the bug is very sensitive to variations in how the alias is used. hgfoo or hgfoo : exhibits the bug, but { hgfoo :; } and (hgfoo) work fine. Using a function instead of an alias also works.

I investigated a bit, trying to extract a smaller example. The weirdness seems to stem from having a newline in the alias. Here is a simple example where bash (3.2.29 or 4.1.9) misbehaves. This alias works as expected (from my reading of Single Unix v3) under pdksh, ksh93, ash and zsh under Debian lenny, namely oops prints foo bar.

$ alias oops='a=$(echo bar)
> echo foo $a'
$ oops
foo foo echo bar

The bug may be related to a reported bug about “strange delayed aliases”, but that discussion focuses on line continuations (backslash-newline) which is not used here.


In any case, use a function! Aliases are for one-liners where you're just specifying some default options for a command. A function would have the additional benefit that you could pass arguments to hg:

hgfoo () {
  localChanges=$(hg st -m "$@")
  …
}

¹ I initially thought this was a Cygwin bug, but as ak2 pointed out, this bug occurs under Linux as well.

This is a bug either in the Cygwin port of bash or in the Cygwin libraries. I could reproduce it on a Windows XP machine running Cygwin 1.7.7-1 with bash 4.1.9(3).

It looks like some of the code is executed both in the parent process and in the child process after a fork. Implementing fork (a fundamental unix concept) on OSes that don't have it (such as Windows) is difficult, especially if you want the implementation to be reasonably efficient. So I'm not altogether surprised to see a bug there.

A few experiments show that the bug is very sensitive to variations in how the alias is used. hgfoo or hgfoo : exhibits the bug, but { hgfoo :; } and (hgfoo) work fine. Using a function instead of an alias also works.

In any case, use a function! Aliases are for one-liners where you're just specifying some default options for a command. A function would have the additional benefit that you could pass arguments to hg:

hgfoo () {
  localChanges=$(hg st -m "$@")
  …
}

This is a long-standing bug in bash's alias expansion. I could reproduce it on Debian lenny amd64 with bash 3.2.29(1), Debian squeeze i386 with 4.1.5(1), and Windows XP with Cygwin 1.7.7-1 with bash 4.1.9(3).

A few experiments show that the bug is very sensitive to variations in how the alias is used. hgfoo or hgfoo : exhibits the bug, but { hgfoo :; } and (hgfoo) work fine. Using a function instead of an alias also works.

I investigated a bit, trying to extract a smaller example. The weirdness seems to stem from having a newline in the alias. Here is a simple example where bash (3.2.29 or 4.1.9) misbehaves. This alias works as expected (from my reading of Single Unix v3) under pdksh, ksh93, ash and zsh under Debian lenny, namely oops prints foo bar.

$ alias oops='a=$(echo bar)
> echo foo $a'
$ oops
foo foo echo bar

The bug may be related to a reported bug about “strange delayed aliases”, but that discussion focuses on line continuations (backslash-newline) which is not used here.


In any case, use a function! Aliases are for one-liners where you're just specifying some default options for a command. A function would have the additional benefit that you could pass arguments to hg:

hgfoo () {
  localChanges=$(hg st -m "$@")
  …
}

¹ I initially thought this was a Cygwin bug, but as ak2 pointed out, this bug occurs under Linux as well.

1
source | link

This is a bug either in the Cygwin port of bash or in the Cygwin libraries. I could reproduce it on a Windows XP machine running Cygwin 1.7.7-1 with bash 4.1.9(3).

It looks like some of the code is executed both in the parent process and in the child process after a fork. Implementing fork (a fundamental unix concept) on OSes that don't have it (such as Windows) is difficult, especially if you want the implementation to be reasonably efficient. So I'm not altogether surprised to see a bug there.

A few experiments show that the bug is very sensitive to variations in how the alias is used. hgfoo or hgfoo : exhibits the bug, but { hgfoo :; } and (hgfoo) work fine. Using a function instead of an alias also works.

In any case, use a function! Aliases are for one-liners where you're just specifying some default options for a command. A function would have the additional benefit that you could pass arguments to hg:

hgfoo () {
  localChanges=$(hg st -m "$@")
  …
}