Dimstar / Dominique Leuenberger writes:

Type is clearly good for interactive use..

type is perfectly usable non-interactively as well.

but $(type ls) will not get you anywhere, whereas $(which ls) actually works

type -p is what you want. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 03/30/2013 04:26 PM, Dimstar / Dominique Leuenberger wrote:

On Sam, 2013-03-30 at 16:24 +0100, Andreas Schwab wrote:

...

Dimstar / Dominique Leuenberger writes:

...

Type is clearly good for interactive use..

type is perfectly usable non-interactively as well.

...

but $(type ls) will not get you anywhere, whereas $(which ls) actually works

type -p is what you want.

Ok, learned something...

yet, this implies changing a bunch of upstream projects autogen.sh, .m4 and other files, simply for the non-reasonable thing of removing (un-announced) which from the base build system.

Dominique, this was AFAIU not intented - neither by Jan as submitter nor by myself during the review. We both expected that this gets caught before checkin, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Quoting Linda Walsh :

Dimstar / Dominique Leuenberger wrote:

...

On Sam, 2013-03-30 at 16:24 +0100, Andreas Schwab wrote:

...

Dimstar / Dominique Leuenberger writes:

...

but $(type ls) will not get you anywhere, whereas $(which ls) actually works type -p is what you want.

Ok, learned something... Dominique

---

It is probably better to use type -P if you are looking for the file on disk..

If there is an alias in place or a function in place i.e. something like:

alias ls='ls -CF --show-control-chars --color=always'

the lower case, "-p" will show a blank whereas "-P" (capital), forced a path search.

Which still does not change the fact that a lot of build scripts use which.. Changing all the scritps / build systems to do "the right thing" will not be done in the next 2 weeks. in plus: the issue has been fixed and everybody moved on to breaking other stuff :) Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 30.03.2013 16:44, schrieb Guido Berhoerster:

* Andreas Schwab [2013-03-30 16:24]:

...

type -p is what you want.

No, it isn't, you want "command -v". In contrast to the "type" bashism, it is specified by POSIX, implemented as a regular builtin in all Bourne-derived shells present in Factory, and perfectly capable of covering the most common use-case of "which", namely printing the pathname of the given utility while taking PATH into account.

But both are not equivalent to "which": seife@susi:~> which ls /usr/bin/ls seife@susi:~> type -p ls seife@susi:~> command -v ls alias ls='ls $LS_OPTIONS' seife@susi:~> -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Guido Berhoerster wrote:

* Stefan Seyfried [2013-03-30 16:57]:

...

Am 30.03.2013 16:44, schrieb Guido Berhoerster:

...

...

type -p is what you want. No, it isn't, you want "command -v". In contrast to the "type" bashism, it is specified by POSIX, implemented as a regular builtin in all Bourne-derived shells present in Factory, and

* Andreas Schwab [2013-03-30 16:24]: perfectly capable of covering the most common use-case of "which", namely printing the pathname of the given utility while taking PATH into account. But both are not equivalent to "which":

seife@susi:~> which ls /usr/bin/ls seife@susi:~> type -p ls seife@susi:~> command -v ls alias ls='ls $LS_OPTIONS'

That is no relevant for script use since there are no aliases in a non-interactive shell.

Unless a caller turned them on: shopt While most of my shopts are only for interactive shells, expand_aliases is too useful in programming in bash to let go. So I have: shopt -s expand_aliases if [ -n "$_sh_interactive_shell" ] ; then if [[ "$BASH_VERSINFO" == '4' ]]; then shopt -s globstar dirspell autocd fi set -o pipefail shopt -s nocaseglob nocasematch expand_aliases shopt -s cdable_vars cdspell checkhash checkwinsize cmdhist dotglob extglob shopt -s histappend histverify hostcomplete lithist histreedit shopt -s no_empty_cmd_completion xpg_echo called from my bashrc, and bash_env I define aliases for keywords like: alias int='declare -i'

int i=1 i+=2 #note, if you don't dcl i an int first, you get string concatenation echo $i 3

comand -v with a function will just give the funcname, not the path there is no way to list the path using the POSIX util. POSIX is lowest common denominator. Back in the 11.x timeframe, you could safely delete a directory contents but not the directory by (cd <dir> && rm -fr --one-filesystem .) There is no other easy expression of that idiom. So POSIX removed it, on the grounds that BSD had it in to protect their students from accidently deleting all files on similar reasoning to the default disabling of rm -fr /. But they are very different. if you try it with the name, depending on the version of coreutils you run, different syntaxes operate differently if the directory name is a symlink. wild cards are out as they can start on start on a submount and delete it too and bash's ** expansion doesn't have an option to stay on 1 file system. You'd have to use 'find' to reconstruct the same behavior they removed to protect the children. rm has to do a depth first traversal when doing a delete, but has a special exception added to inspect the top directory first and if it ".", then abort the normal traveral (with -f suppressing any error messages about not being able to delete ".". Don't suppse suse would want a patch fixing that....so it's useful again... I happen to have one available for some reason or another... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Saturday 2013-03-30 16:24, Andreas Schwab wrote:

Dimstar / Dominique Leuenberger writes:

...

Type is clearly good for interactive use..

type is perfectly usable non-interactively as well.

...

but $(type ls) will not get you anywhere, whereas $(which ls) actually works

type -p is what you want.

It is not. If "ls" is an alias, `type -p ls` will return nothing, while `which ls` continues to yield the path to the program. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andreas Schwab wrote:

Jan Engelhardt writes:

...

It is not. If "ls" is an alias, `type -p ls` will return nothing, while `which ls` continues to yield the path to the program.

A noninteractive shell has no aliases.

I even have some I save and propagate in the ENV to children

Andreas.

Mind do. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sam, 2013-03-30 at 14:44 +0100, Jan Engelhardt wrote:

On Saturday 2013-03-30 13:18, Dimstar / Dominique Leuenberger wrote:

...

As a wrapup: the 'submit' came in with: https://build.opensuse.org/request/show/161218

The submitter added as submit text: "Please wait for which, adjtimex, time to go in first since those packages have been split from util-linux."

Hm that would suggest that reviewers don't read the message..

Reviewers do.. but 'checkiners' don't :) which is currently pending legal review as it seems... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 30.03.2013 14:44, Jan Engelhardt wrote:

On Saturday 2013-03-30 13:18, Dimstar / Dominique Leuenberger wrote:

...

As a wrapup: the 'submit' came in with: https://build.opensuse.org/request/show/161218

The submitter added as submit text: "Please wait for which, adjtimex, time to go in first since those packages have been split from util-linux."

Hm that would suggest that reviewers don't read the message..

The reviewers read it, but if they pass the review, the checkin is going almost unintended.

...

* Are we (packagers) now supposed to add BuildRequires: which to whatever uses it (I don't object it.. but where does it stop?)

IMO, a Support: entry should be added to the prjconfs of Base:System and openSUSE:Factory.

No. But I already submitted a rpm-build package that requires which, but as which is still in legal-team review, I had to actually ignore the dependency Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org