...

I have created a new package wcd for openSUSE. Wcd is a shell utility to change directory fast on the command line.

The "wcd" function is prone to race conditions because all invocations use the same file. That raises the question, why use a file at all? At least on Linux where pipes properly work and ttys exist, there is no need for additional temporary files. wcd () { go="${WCDHOME:-${HOME}}/bin/wcd.go"; rm -f "$go" 2> /dev/null; /usr/bin/wcd.exe "$@"; [ -f "$go" ] && . "$go"; unset go }

...

See also http://waterlan.home.xs4all.nl/#WCD_ANCHOR

Wcd is a mature application. I am also the upstream maintainer of Wcd.

Yesterday I have done a submit request the wcd package to devel project utilities (https://build.opensuse.org/project/show/utilities). The request is still open.

The documentation directory should probably be called /usr/share/doc/packages/wcd rather than wcd-5.2.25 since it is impossible to coinstall two versions currently.

I recently got confused between the packages available on openSUSE named WICD, pronounced "wicked", and Wicked, pronounced "wicked". Now we are to have "wcd", pronounced . . . ? ;-)

Uh, well, WCD? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Oct 16, 2014 at 7:25 PM, waterlan wrote:

Jan Engelhardt schreef op 2014-10-16 13:28:

...

...

...

I have created a new package wcd for openSUSE. Wcd is a shell utility to change directory fast on the command line.

The "wcd" function is prone to race conditions because all invocations use the same file.

No. Every user has its own 'go script'. And a user will not type the wcd command twice at the same time.

You mean user or process? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 17 Oct 2014 00:25, waterlan wrote:

Jan Engelhardt schreef op 2014-10-16 13:28:

...

...

...

I have created a new package wcd for openSUSE. Wcd is a shell utility to change directory fast on the command line.

The "wcd" function is prone to race conditions because all invocations use the same file.

No. Every user has its own 'go script'. And a user will not type the wcd command twice at the same time.

Playing Devils' Advocat: O'rly? Multiple xterms? To get sure of at least that, you would have to use either the $PPID, or the tty/pty-id to differate that.

...

That raises the question, why use a file at all? At least on Linux where pipes properly work and ttys exist, there is no need for additional temporary files.

A file works fine. See above.

It's not about raining onto your parade, it's about pointing out potential problems. Better get answers to that now than later. About the name, I would speak it "We-CD" and CD like in Compact-Disc. - Yamaban -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 10/17/2014 07:56 AM, Erwin Waterlander wrote:

Op 17-10-2014 0:39 Yamaban schreef:

...

On Fri, 17 Oct 2014 00:25, waterlan wrote:

...

Jan Engelhardt schreef op 2014-10-16 13:28:

...

The "wcd" function is prone to race conditions because all invocations use the same file.

No. Every user has its own 'go script'. And a user will not type the wcd command twice at the same time.

Playing Devils' Advocat: O'rly? Multiple xterms?

With two keyboards, and four hands? Perhaps the devil can do that, but I can't. ;)

Shared accounts are not unusual on servers. So if 2 persons are using the same account and `wcd` at the same time ... ... "yes, we can". ;-) Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 10/17/2014 04:49 PM, Erwin Waterlander wrote:

The two persons can set a different WCDHOME variable. They would need to do that already if they don't want to share the (extra) tree data, bans, excludes, aliases, and stack. The two users would need to make some personal setup on the shared account anyway, for instance for their personal aliases or vim editor settings.

Why? I mean all of them can use the same settings for that single account, and they can simultaneously run vim, the aliases ... but not wcd. ;-/ Couldn't it just write to stdout? wcd () { local out="$( env wcd "$@")" || return test "$out" && eval "$out" } (I didn't look at wcd too much - especially the output, so eval might be the wrong approach. It must be more complicated, otherwise directly cd-ing to "$out" would be the obvious way.) Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Op 17-10-2014 17:14 Bernhard Voelker schreef:

On 10/17/2014 04:49 PM, Erwin Waterlander wrote:

...

The two persons can set a different WCDHOME variable. They would need to do that already if they don't want to share the (extra) tree data, bans, excludes, aliases, and stack. The two users would need to make some personal setup on the shared account anyway, for instance for their personal aliases or vim editor settings.

Why? I mean all of them can use the same settings for that single account, and they can simultaneously run vim, the aliases ... but not wcd. ;-/

I would not want to use my colleagues aliases and vim settings...

Couldn't it just write to stdout?

wcd () { local out="$( env wcd "$@")" || return test "$out" && eval "$out" }

Yes it can. wcd () { cd "$($HOME/bin/wcd.exe -GN -j $@)" } but then you loose the option to choose when you have multiple matches. And that is not handy when you have a lot of folders in the tree index. Normally when there are multiple matches, or when you want to see the stack, an ncurses interface is launched. This sort of breaks the stdout method. Perhaps it is possible, but I did not look into that for a long time. best regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Oct 17, 2014 at 2:56 AM, Erwin Waterlander wrote:

Op 17-10-2014 0:39 Yamaban schreef:

...

On Fri, 17 Oct 2014 00:25, waterlan wrote:

...

Jan Engelhardt schreef op 2014-10-16 13:28:

...

...

...

I have created a new package wcd for openSUSE. Wcd is a shell utility to change directory fast on the command line.

The "wcd" function is prone to race conditions because all invocations use the same file.

No. Every user has its own 'go script'. And a user will not type the wcd command twice at the same time.

Playing Devils' Advocat: O'rly? Multiple xterms?

With two keyboards, and four hands? Perhaps the devil can do that, but I can't. ;)

Broadcasted terminals (see terminator broadcast). Slight human error can make you broadcast to the same server, and kaputt. Cronjobs, using wcd inside a cron is probably not a very good idea, but someone might think it dandy to not have to type the whole path, and then you can run into trouble (not only the race condition of course, but it would be possible for wcd to race another wcd for sure). In any case, using the user alone is a poor choice when you have the shell's PID. Use that, it takes almost no effort. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Oct 20, 2014 at 3:30 PM, Erwin Waterlander wrote:

On 10/17/2014 04:18 PM, Claudio Freire wrote:

...

Cronjobs, using wcd inside a cron is probably not a very good idea, but someone might think it dandy to not have to type the whole path, and then you can run into trouble (not only the race condition of course, but it would be possible for wcd to race another wcd for sure).

wcd is intended for interactive usage, not for scripts. I only have one nightly cron job that scans my home drive. For this the function is not needed, the binary can be called directly.

I know, but people will abuse it. Be ready for bug reports. And it *is* a bug. What's this reluctance to use the shell's PID as someone suggested? It's a trivial enough change. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Friday 2014-10-17 00:25, waterlan wrote:

Jan Engelhardt schreef op 2014-10-16 13:28:

...

...

...

I have created a new package wcd for openSUSE. Wcd is a shell utility to change directory fast on the command line.

The "wcd" function is prone to race conditions because all invocations use the same file.

a user will not type the wcd command twice at the same time.

Famous last words... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Graham P Davis schreef op 2014-10-16 11:44:

On Wed, 15 Oct 2014 22:04:59 +0200 Erwin Waterlander wrote:

...

Hi,

I have created a new package wcd for openSUSE. Wcd is a shell utility to change directory fast on the command line. See also http://waterlan.home.xs4all.nl/#WCD_ANCHOR

Wcd is a mature application. I am also the upstream maintainer of Wcd.

Yesterday I have done a submit request the wcd package to devel project utilities (https://build.opensuse.org/project/show/utilities). The request is still open.

I recently got confused between the packages available on openSUSE named WICD, pronounced "wicked", and Wicked, pronounced "wicked". Now we are to have "wcd", pronounced . . . ? ;-)

double u cee dee Or try in Dutch, it sounds like: way cay day. ;) -- Erwin Waterlander http://waterlan.home.xs4all.nl/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andreas Schwab schreef op 2014-10-21 09:58:

%{_bindir}/wcd.exe should be moved to %{_libdir}, since it is not supposed to be called directly

I will change this.

(and wcd.exe is a weird name).

It is a valid name, but some people don't like it because it reminds them of Windows. I will change it.

$HOME/bin is not guaranteed to exist.

It will be automatically created.

Really the the wcd function should not use any files at all.

For now I postpone this issue to later.

Also, it clobbers the go shell variable.

Can you explain? Thanks for the feedback. best regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andreas Schwab schreef op 2014-10-21 10:34:

Erwin Waterlander writes:

...

...

Also, it clobbers the go shell variable.

Can you explain?

The function overwrites it.

You are right. I fix it. Thanks. -- Erwin Waterlander http://waterlan.home.xs4all.nl/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andreas Schwab schreef op 2014-10-21 10:38:

Erwin Waterlander writes:

...

...

$HOME/bin is not guaranteed to exist.

It will be automatically created.

It's not the right place for temporary files.

I know, but I want to keep it there for backward compatibility. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andreas Schwab schreef op 2014-10-21 12:55:

Erwin Waterlander writes:

...

Andreas Schwab schreef op 2014-10-21 10:38:

...

Erwin Waterlander writes:

...

...

$HOME/bin is not guaranteed to exist.

It will be automatically created.

It's not the right place for temporary files.

I know, but I want to keep it there for backward compatibility.

Which compatibility? This is an implementation detail of wcd.

For all those people who manually created the function. Those are a lot over the past 18 years, and I don't want to bother them. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andreas Schwab schreef op 2014-10-21 14:13:

Erwin Waterlander writes:

...

Andreas Schwab schreef op 2014-10-21 12:55:

...

Erwin Waterlander writes:

...

Andreas Schwab schreef op 2014-10-21 10:38:

...

Erwin Waterlander writes:

...

> $HOME/bin is not guaranteed to exist.

It will be automatically created.

It's not the right place for temporary files.

I know, but I want to keep it there for backward compatibility.

Which compatibility? This is an implementation detail of wcd.

For all those people who manually created the function. Those are a lot over the past 18 years, and I don't want to bother them.

They will continue to use the function they defined on their own.

The bin sub-folder is default on Unix. That is set in the binary and is also documented. I can use the -G option to change the location, but I don't want to do that in the default function. When the option -G is used WCDHOME has no influence on the location of the go-script anymore. This may surprise users. I leave the use of -G to personal configurations. Because it is a shell script, and personal scripts are put typically in ~/bin, I was thinking 18 years ago to put this one there too. Perhaps wrong, but it is not a big deal. If it is a problem for a user he/she can always change the location. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, 21 Oct 2014 19:05, Claudio Freire wrote:

On Tue, Oct 21, 2014 at 1:15 PM, Erwin Waterlander wrote:

...

Andreas Schwab schreef op 2014-10-21 14:13:

...

Erwin Waterlander writes:

...

Andreas Schwab schreef op 2014-10-21 12:55:

...

Erwin Waterlander writes:

...

Andreas Schwab schreef op 2014-10-21 10:38: > Erwin Waterlander writes: >>> >>> $HOME/bin is not guaranteed to exist.

~/bin should be created at first user login due to /etc/skel

...

...

...

...

...

>> It will be automatically created. > > It's not the right place for temporary files.

I know, but I want to keep it there for backward compatibility.

Which compatibility? This is an implementation detail of wcd.

For all those people who manually created the function. Those are a lot over the past 18 years, and I don't want to bother them.

They will continue to use the function they defined on their own.

The bin sub-folder is default on Unix. That is set in the binary and is also documented. I can use the -G option to change the location, but I don't want to do that in the default function. When the option -G is used WCDHOME has no influence on the location of the go-script anymore. This may surprise users. I leave the use of -G to personal configurations. Because it is a shell script, and personal scripts are put typically in ~/bin, I was thinking 18 years ago to put this one there too. Perhaps wrong, but it is not a big deal. If it is a problem for a user he/she can always change the location.

Well, TBH, I don't think putting an executable script in /tmp is a good idea either. I'm pretty sure the security guys will complain if done like that. I prefer something in home than in /tmp. In that sense, while ~/bin isn't the right place (I'd rather go for ~/tmp if it was standard), it's the safest choice ATM. The function only has to be really sure it's not clobbering any existing script there, and that folder permissions are not too permissive.

Hmm, how about a folder "wcd" under "~/.local"? .local/ is in /etc/skel, and is conform to the freedesktop standards, OTOH, maybe the dir ~/.config/ is better, but you have to create it with mode 0700 if it isn't there already (not in skel). - Yamaban -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, 21 Oct 2014 19:30, Andrei Borzenkov wrote:

On Tue, 21 Oct 2014 19:21, Yamaban wrote:

...

On Tue, 21 Oct 2014 19:05, Claudio Freire wrote:

...

On Tue, Oct 21, 2014 at 1:15 PM, Erwin Waterlander wrote:

...

Andreas Schwab schreef op 2014-10-21 14:13:

...

Erwin Waterlander writes:

...

Andreas Schwab schreef op 2014-10-21 12:55: > Erwin Waterlander writes: >> Andreas Schwab schreef op 2014-10-21 10:38: >>> Erwin Waterlander writes: {snip} Well, TBH, I don't think putting an executable script in /tmp is a good idea either. I'm pretty sure the security guys will complain if done like that. I prefer something in home than in /tmp. In that sense, while ~/bin isn't the right place (I'd rather go for ~/tmp if it was standard), it's the safest choice ATM. The function only has to be really sure it's not clobbering any existing script there, and that folder permissions are not too permissive.

Hmm, how about a folder "wcd" under "~/.local"?

$XDG_RUNTIME_DIR?

...

.local/ is in /etc/skel, and is conform to the freedesktop standards, OTOH, maybe the dir ~/.config/ is better, but you have to create it with mode 0700 if it isn't there already (not in skel).

The trouble with $XDG_* is that I can not get that to work well without having a valid Xsession. Not so good for remote work via ssh. That is why I brought ~/.local/{program} and ~/.config/{program} into the discussion. Yes, testing for /run/user/{UID}/ can also be done, but I still find systems without /run/user/ or /var/run/user/ structure. - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 10/21/2014 07:44 PM, Yamaban wrote:

On Tue, 21 Oct 2014 19:30, Andrei Borzenkov wrote:

...

On Tue, 21 Oct 2014 19:21, Yamaban wrote:

...

On Tue, 21 Oct 2014 19:05, Claudio Freire wrote:

...

On Tue, Oct 21, 2014 at 1:15 PM, Erwin Waterlander wrote:

...

Andreas Schwab schreef op 2014-10-21 14:13:

...

Erwin Waterlander writes: > Andreas Schwab schreef op 2014-10-21 12:55: >> Erwin Waterlander writes: >>> Andreas Schwab schreef op 2014-10-21 10:38: >>>> Erwin Waterlander writes: {snip} Well, TBH, I don't think putting an executable script in /tmp is a good idea either. I'm pretty sure the security guys will complain if done like that. I prefer something in home than in /tmp. In that sense, while ~/bin isn't the right place (I'd rather go for ~/tmp if it was standard), it's the safest choice ATM. The function only has to be really sure it's not clobbering any existing script there, and that folder permissions are not too permissive.

Hmm, how about a folder "wcd" under "~/.local"?

$XDG_RUNTIME_DIR?

...

.local/ is in /etc/skel, and is conform to the freedesktop standards, OTOH, maybe the dir ~/.config/ is better, but you have to create it with mode 0700 if it isn't there already (not in skel).

The trouble with $XDG_* is that I can not get that to work well without having a valid Xsession. Not so good for remote work via ssh.

That is why I brought ~/.local/{program} and ~/.config/{program} into the discussion.

Yes, testing for /run/user/{UID}/ can also be done, but I still find systems without /run/user/ or /var/run/user/ structure.

I find backward compatibility and portability very important. Wcd is still compatible with the first version, and many shells are supported. I'm not optimizing for specific Unix (like) systems. regards, Erwin -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2014-10-21 09:58, Andreas Schwab wrote:

%{_bindir}/wcd.exe should be moved to %{_libdir}, since it is not supposed to be called directly (and wcd.exe is a weird name).

That should be %_libexecdir in fact. As for the name, what's in a name. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2014-10-21 21:23, Erwin Waterlander wrote:

On 10/21/2014 10:31 AM, Jan Engelhardt wrote:

...

On Tuesday 2014-10-21 09:58, Andreas Schwab wrote:

...

%{_bindir}/wcd.exe should be moved to %{_libdir}, since it is not supposed to be called directly (and wcd.exe is a weird name). That should be %_libexecdir in fact. As for the name, what's in a name.

What I read is that libexec is intended for programs that are not intended to be be executed directly by users or shell scripts. In other words, libexec is for programs called by programs.

It is not that strict. The point is simply that /usr/lib(exec)/whatever/ is not going to be in the $PATH, so calling a program there usually requires specifying the full path. libexec is for programs invoked by other “routines”, i.e. abstract mechanisms that conveniently hide the full path from the user. That may be programs, scripts, sh aliases, or even symlinks: /sbin/init is just a symlink to /usr/lib/systemd/systemd, too, you know.

Second, I read that Suse does not support libexec. It is also not present on my openSUSE 13.1 installation.

We do support the concept of libexec. (GNU packages sort of demand it.) It just so happens that we defined the libexec directory to be /usr/lib, which coincides with %_libdir on some (but not all) platforms. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 10/22/2014 09:07 AM, Erwin Waterlander wrote:

Jan Engelhardt schreef op 2014-10-22 02:12:

...

On Tuesday 2014-10-21 21:23, Erwin Waterlander wrote:

...

On 10/21/2014 10:31 AM, Jan Engelhardt wrote:

...

On Tuesday 2014-10-21 09:58, Andreas Schwab wrote:

...

%{_bindir}/wcd.exe should be moved to %{_libdir}, since it is not supposed to be called directly (and wcd.exe is a weird name). That should be %_libexecdir in fact. As for the name, what's in a name.

What I read is that libexec is intended for programs that are not intended to be be executed directly by users or shell scripts. In other words, libexec is for programs called by programs.

It is not that strict.

The point is simply that /usr/lib(exec)/whatever/ is not going to be in the $PATH, so calling a program there usually requires specifying the full path.

libexec is for programs invoked by other “routines”, i.e. abstract mechanisms that conveniently hide the full path from the user. That may be programs, scripts, sh aliases, or even symlinks: /sbin/init is just a symlink to /usr/lib/systemd/systemd, too, you know.

...

Second, I read that Suse does not support libexec. It is also not present on my openSUSE 13.1 installation.

We do support the concept of libexec. (GNU packages sort of demand it.) It just so happens that we defined the libexec directory to be /usr/lib, which coincides with %_libdir on some (but not all) platforms.

OK, thanks for the info. I fix it.

I have uploaded the changes. See https://build.opensuse.org/request/show/258141 regards, Erwin -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org