On 27/06/12 11:14, Dan McGee wrote: > On Tue, Jun 26, 2012 at 6:51 PM, Dave Reisner <[email protected]> wrote: >> On Wed, Jun 27, 2012 at 08:58:09AM +1000, Allan McRae wrote: >>> Extract the download protocol from a source entry. Returns "local" >>> for local source files. >>> >>> Signed-off-by: Allan McRae <[email protected]> >>> --- >>> scripts/makepkg.sh.in | 11 +++++++++++ >>> 1 file changed, 11 insertions(+) >>> >>> diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in >>> index 4299816..0d87cba 100644 >>> --- a/scripts/makepkg.sh.in >>> +++ b/scripts/makepkg.sh.in >>> @@ -222,6 +222,17 @@ get_url() { >>> printf "%s\n" "${1#*::}" >>> } >>> >>> +# extract the protocol from a source entry - return "local" for local >>> sources >>> +get_protocol() { >>> + if [[ $1 = *://* ]]; then >>> + # strip leading filename >>> + local proto="${1##*::}" >>> + printf "%s\n" "${proto%%://*}" >> >> While we're here, should we catch file:// protos and return 'local' as >> well? It would save the end user from having to define file:// as a >> DLAGENT. > > Shouldn't we just return "file" instead of make up a "local" protocol, > while we're on this train of thought? >
Hmm.... this could be interesting... local assumes that the file is in $startdir. I guess file:// could be used to specify files anywhere on your system, but that really does not make a portable PKGBUILD. I'm tempted to say all local files must be in $startdir and so no support of file:// is needed. Allan
