Bugs in bash.bashrc

Using XFCE on openSUSE 13.1, my bash.bashrc has 2 bugs in it. Both of them are when a custom function/routine is the same name as an internal command.

1st bug is at line 57. This line:

path ()

Generates this error:

-bash: /etc/bash.bashrc: line 57: syntax error near unexpected token `('
-bash: /etc/bash.bashrc: line 57: `path ()'

There is nothing syntactically wrong with that line - bash just doesn’t like creating a function with the same name as a built-in command. Doing a global search and replace that changes “path” to “ckpath” fixes the error.

Once that bug was fixed, this error appeared:

-bash: /etc/profile.d/alias.bash: line 12: syntax error near unexpected token `('
-bash: /etc/profile.d/alias.bash: line 12: `    remount () { /bin/mount -o remount,${1+"$@"} ; }'

Since there is a built-in remount command, and I never use remount anyway, I just commented out line 12 in /etc/profile.d/alias.bash

It is not uncommon to have reserved keywords in any program language.

I cannot find a built-in command on your examples. Also careful when defining your function/alias names check it if is defined already using some test before deciding to use it, you said you fix the ‘bug’ by editing it manually? Wrong move because a simple reinstall of the package the includes that bash config file will revert to the original.
rpm -qf /etc/bash.bashrc to see which package it belongs to. Last thing there is no bug, underscore is allowed in bash function/alias names to avoid collision with others.

I am describing a system-provided file that does not work as-is in the most recent version of openSUSE. That’s a bug.

So fixing this “bug” on my own system was the wrong thing to do? What do you propose, that I live with a broken shell? Oh wait, this isn’t a bug - maybe the error messages were just my imagination.

If someone finds this post while searching for this non-bug, maybe my non-fix will help. Or maybe it won’t.

It seems to work as-is for everyone other than you. I’m not sure what you are doing differently.

Personally, I hold to the school of thought that says “/etc/bash.rc” (and similar files) belongs to the local system administrator, not to the system vendor. But the world doesn’t seem to agree with me.

I don’t know why you are having this problem. I do know that people would be screaming if this were really a bug.

Normally, I use “csh”, and I do edit “/etc/csh.cshrc” to my liking. So I started “bash” in a terminal. I am not getting any error from line 57. The output of “set” shows that the “path()” function has been defined in accordance with the definition given in “/etc/bash.bashrc”.

On 2014-03-08 22:16, ThomasMcA wrote:
>
> I am describing a system-provided file that does not work as-is in the
> most recent version of openSUSE. That’s a bug.
>
> So fixing this “bug” on my own system was the wrong thing to do? What do
> you propose, that I live with a broken shell? Oh wait, this isn’t a bug
> - maybe the error messages were just my imagination.

But I’m not seeing any error message… where do you see them?

> If someone finds this post while searching for this non-bug, maybe my
> non-fix will help. Or maybe it won’t.

But bugs are not reported here. Nobody will do anything about what you
report here. You have to report in Bugzilla.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

What does not work? can you provide more info? Also how is your shell broken?

If you edit those files which came from a package then it might depend on other config files provided by a package, thats the reason for your other so called error after you have fixed your so called bug.

Do you know what a built-in command/executable is? and how can you tell it from the external command/executable?

To clear things up i have just installed xfce 13.1 virtualmachine and on an external usb drive, i have tested it without updating and it did not have the error/bug that you are talking about.

I ran the update and i still cannot reproduce what you’re talking about even if i run ** path ( )** no error whatsoever only a literal > that comes out of it. The only time i have encounter something like what you’re describing is when i was messing with my aliases and function names.

If you created a function that has the same name with an alias or vice versa ( i cannot remember which one is it ) then you will get that error. Now please stop saying built-in and broken shell because you do not know what you're talking about.  

Stop downloading scripts and config files from the internet that you do not know nothing about and running and installing it in your system.  If you run:  **type -a path**  and **type -a remount**  you should see if it is a builtin/function/alias/ or an executable in your PATH. Bash completion normally use underscores when defining function names to avoid collision with another similar function/alias name have a look inside /etc/bash_completion.d and see for yourself about the use of undescores. I hope i have shed some light on this issue ;)