Bug 1076823 - /usr/libexec/mariadb-* scripts should not use "./mariadb-scripts-common" for sourcing
Summary: /usr/libexec/mariadb-* scripts should not use "./mariadb-scripts-common" for ...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: mariadb
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Honza Horak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-15 12:21 UTC by Robert P. J. Day
Modified: 2014-03-27 13:11 UTC (History)
6 users (show)

Fixed In Version: mariadb-server-5.5.36-2.fc21
Clone Of:
Environment:
Last Closed: 2014-03-26 16:51:59 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Robert P. J. Day 2014-03-15 12:21:29 UTC
Two /usr/libexec/ helper scripts for mariadb-server:

  * mariadb-check-socket
  * mariadb-prepare-db-dir

contain the sourcing line:

  source ./mariadb-scripts-common

I don't see how that can work as "source" normally relies on the PATH variable to find scripts being sourced. I would think you need the full pathname here, as in:

  source /usr/libexec/mariadb-scripts-common

or something equivalent. If I make that fix, then things appear to work properly.

  And while I'm here, that "mariadb-scripts-common" script would probably look better if it was marked executable, but that't not critical.

Comment 1 Robert P. J. Day 2014-03-15 12:39:12 UTC
Whoops, forgot to mention that /usr/libexec/mariadb-wait-ready has same issue.

Comment 2 Filipe Rosset 2014-03-22 23:37:27 UTC
hi guys, same issue here with an fully updated rawhide installation. the workaround mentioned by Robert is working fine.

Comment 3 Honza Horak 2014-03-24 15:03:50 UTC
Thanks for reporting, will fix asap.

Comment 4 Honza Horak 2014-03-26 16:51:59 UTC
Should be fixed now. I've used this:

  source "`dirname ${BASH_SOURCE[0]}`/mariadb-scripts-common"

because I don't like hard-coded paths.

Comment 5 Robert P. J. Day 2014-03-27 08:47:25 UTC
I'm curious ... how did this bug come to be? It seems so odd that one suspects there might be other instances of it in other packages. What is the standard way of doing this in other Red Hat packages?

Comment 6 Honza Horak 2014-03-27 12:07:19 UTC
(In reply to Robert P. J. Day from comment #5)
> I'm curious ... how did this bug come to be? It seems so odd that one
> suspects there might be other instances of it in other packages. What is the
> standard way of doing this in other Red Hat packages?

I may not follow you, since it's more about how this is done in Bash, I'd say. At least in case I don't want to use hard-coded full path, which would be more straightforward solution, but wouldn't work for SCL at least.

Anyway, if I want to source some file from relative path in Bash (the same directory in this case), I need to use dirname ${BASH_SOURCE[0]} -- at least that's what I learnt from the source(1) man page:

source filename [arguments]
Read  and execute commands from filename in the current shell environment and return the exit status of the last command executed from filename.  If filename does not contain a  slash,  file  names  in PATH  are used to find the directory containing filename.  The file searched for in PATH need not be executable.  When bash is not in posix mode, the current directory is searched if no file  is  found in  PATH.   If  the  sourcepath  option  to the shopt builtin command is turned off, the PATH is not searched.  If any arguments are supplied, they become the positional  parameters  when  filename  is executed.   Otherwise  the  positional parameters are unchanged.  The return status is the status of the last command exited within the script (0 if no commands are executed), and false if filename  is not found or cannot be read.

Any more pretty ideas are welcome of course.


Note You need to log in before you can comment on or make changes to this bug.