Greetings,

This is a weird error, the run task function is creating e temporary file in /tmp puts the command in it and some additional commands so the shell won't exit before you press ENTER: http://git.gnome.org/browse/gnome-schedule/tree/src/mainWindow.py#n706 - then runs the file in your configured terminal.

If you could press the 'Run task' button, check your /tmp folder and look for a file around 8 chars long with both letters and numbers containing your command and some extra stuff, post that here - that would be very helpful.

The tmp file is generated automatically so I can't tell you the exact name.

Thanks, Gaute

-r-x------  1 rbeede rbeede      125 2010-03-11 10:30 tmpmbmerk

rbeede@rodneybeede:/tmp$ cat tmpmbmerk 
/bin/bash /media/DATA/Work/Backup_Tools/backup_to_network.bash
echo Press ENTER to continue and close this window.
read
exit



rbeede@rodneybeede:/tmp$ cat /media/DATA/Work/Backup_Tools/backup_to_network.bash
echo Start command was $0

if [ ! -d /tmp ]
then
	mkdir /tmp/smb
fi

chmod 0700 /tmp/smb

PATH=$PATH:/bin:/sbin:/usr/bin:/usr/sbin

/usr/local/samba/sbin/mount.cifs //windows-server/Users/rbeede /tmp/smb -o credentials=/home/rbeede/.private/.smbclient,rw,dir_mode=0700,file_mode=0600

perl dostuff.pl /tmp/smb

/usr/local/samba/sbin/umount.cifs /tmp/smb

I also tried moving the script backup_to_network.bash to /tmp and making it executable.  Same issue.  I also added #!/bin/bash to the top of it and renamed it to just backup_to_network.  Same problem.

  > rbeede@rodneybeede:/tmp$ cat tmpmbmerk
  > /bin/bash /media/DATA/Work/Backup_Tools/backup_to_network.bash
  > echo Press ENTER to continue and close this window.
  > read
  > exit
                    
  Does the 'Press ENTER' part show up in your terminal before or after the
  password prompt? Is the password prompt in the terminal or a graphical
  one of some sorts, in other words; what is asking for the password?

  - (3 quoted lines)
  > rbeede@rodneybeede:/tmp$ cat
  > /media/DATA/Work/Backup_Tools/backup_to_network.bash
  > echo Start command was $0

  Does this part show up in the terminal?

  When I say terminal I mean the one that pops up when you click 'Run
  task'.

  Thanks, Gaute

Press ENTER shows up after the Password prompt


Password prompt is in the Terminal window.  It is coming from the mount.cifs command although it shouldn't be prompting.

The echo Start command was $0 does output in the terminal with "Start command was /media/DATA/Work/Backup_Tools/backup_to_network.bash"

(In reply to comment #5)
> Press ENTER shows up after the Password prompt
> 
> 
> Password prompt is in the Terminal window.  It is coming from the mount.cifs
> command although it shouldn't be prompting.
> 
> The echo Start command was $0 does output in the terminal with "Start command
> was /media/DATA/Work/Backup_Tools/backup_to_network.bash"

Hm - I doubt that this problem is specific to Gnome Schedule. Are you using Gnome and gnome-terminal?

Could you run the temp file like this from a shell/terminal:
$ gnome-terminal -x /tmp/whatever

(possibly check what you're 'Default terminal' is configured to under Settings -> Preferred applications, I'm not using Ubuntu so can't tell you more exact)

and directly:
$ /tmp/whatever

See if you get the same behavior. I really don't have any idea what the problem can be yet.

- gaute

System -> Preferences -> Preferred Applications
  System tab -> Terminal Emulator

  GNOME Terminal
   Command:  gnome-terminal
   Execute flag:  -x

If I change it to Standard XTerminal (xterm) then clicking on the run button causes nothing to happen at all.


When I do gnome-terminal -x /tmp/tmpLj6Pdy I get the same result.

When I do a direct /tmp/tmpLj6Pdy I get the same result.


However if I close all terminal windows and open a new one via Applications -> Accessories -> Terminal and run /tmp/tmpLj6Pdy directly then it works as expected.


It's interesting to note the following:

Close all open terminal windows

Open gnome-schedule

Select the task

"Run selected task" button

Terminal window appears with Password: prompt

Leave terminal window open and open another terminal using Applications -> Accessories -> Terminal

Make a copy of the /tmp/tmpXXXXX file to /tmp/testrun
  (tmpXXXXX is busy/locked so this is necessary)

In new terminal window run /tmp/testrun

Notice that Password prompt appears

Also sometimes the new terminal opens up but ignores my ~/.profile which is suppose to configure some things.


So it seems the way that gnome-schedule is opening the terminal is causing strange behavior for the entire OS afterwards?

Gnome-schedule is using gnome.execute_terminal_shell (http://library.gnome.org/devel/libgnome/stable/libgnome-gnome-exec.html#gnome-execute-terminal-shell) so it is basically just using the same gnome function that any other gnome program would use to execute something in a terminal.

from src/mainWindow.py:715: the command that is executed or passed would be
$ gnome-schedule -x /bin/bash /tmp/tmpXXXXX

this is run in your home dir.

In case you have something in your .profile to get the password and it is not run if it is not a login shell, check your .bashrc or .profile, there should be comments about it? Some test that exists if its not, that might be a reason as i'm not sure if it is considered a login shell.. (try 'bash -l' as the first command in a terminal that normally doesn't work)

- gaute

Didn't see anything.  I even renamed my .profile and .bashrc so they wouldn't be used at all.  Same thing.  It is strange that's for sure.

I even set PS1 to a value since some programs use that to detect interactive shells.  No dice.

I'm going to read through the source code for mount.cifs to see if I can see any if statements that would cause it to ignore the credentials file.

My .profile:

# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.

# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022

# if running bash
if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
	. "$HOME/.bashrc"
    fi
fi

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi




==============================================
My .bashrc (stock with Ubuntu 9.10):

# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

# don't put duplicate lines in the history. See bash(1) for more options
# don't overwrite GNU Midnight Commander's setting of `ignorespace'.
HISTCONTROL=$HISTCONTROL${HISTCONTROL+,}ignoredups
# ... or force ignoredups and ignorespace
HISTCONTROL=ignoreboth

# append to the history file, don't overwrite it
shopt -s histappend

# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)

# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize

# make less more friendly for non-text input files, see lesspipe(1)
[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"

# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "$debian_chroot" ] && [ -r /etc/debian_chroot ]; then
    debian_chroot=$(cat /etc/debian_chroot)
fi

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
    xterm-color) color_prompt=yes;;
esac

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
    if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
	# We have color support; assume it's compliant with Ecma-48
	# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
	# a case would tend to support setf rather than setaf.)
	color_prompt=yes
    else
	color_prompt=
    fi
fi

if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
    PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
    ;;
*)
    ;;
esac

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls --color=auto'
    #alias dir='dir --color=auto'
    #alias vdir='vdir --color=auto'

    alias grep='grep --color=auto'
    alias fgrep='fgrep --color=auto'
    alias egrep='egrep --color=auto'
fi

# some more ls aliases
alias ll='ls -la'
#alias la='ls -A'
#alias l='ls -CF'
alias vim='vi'

# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
    . /etc/bash_completion
fi


export MAVEN_OPTS="-Xms1g -Xmx1g -DdownloadSources=true -DdownloadJavadocs=true"

So I modified the code for mount.cifs and recompiled it with lots of printf debug statements.

It appears that all the options are not being parsed for some reason.  Either a bug in mount.cifs options parsing or a bug with the character encoding?  I'm using UTF-8 and my terminal should be that too.

I'm going to debug with the mount.cifs program some more to see how it is getting the information passed differently somehow.

I figured it out!

mount.cifs.c calls 	while ((c = getopt_long (argc, argv, "afFhilL:no:O:rsSU:vVwt:",
			 longopts, NULL)) != -1) {


From the man page for getopt_long:

POSIXLY_CORRECT  If set, option processing stops when the first non-
                      option is found and a leading `-' or `+' in the
                      optstring is ignored.


So on a user opened terminal POSIXLY_CORRECT is NOT set.
When running the script via the cron scheduled time POSIXLY_CORRECT is NOT set.

When running the script via the Run selected task button POSIXLY_CORRECT WAS set.

I added "unset POSIXLY_CORRECT" to my script, and it worked!  Annoying that the getopt_long has that feature.

Perhaps gnome-schedule should unset that environment variable?

You can't do POSIXLY_CORRECT=disabled or even POSIXLY_CORRECT=  because just the existence of the environment variable will trigger it.

I've also filed a bug report with Samba about this issue.

https://bugzilla.samba.org/show_bug.cgi?id=7242

(In reply to comment #12)
> Perhaps gnome-schedule should unset that environment variable?
> 
> You can't do POSIXLY_CORRECT=disabled or even POSIXLY_CORRECT=  because just
> the existence of the environment variable will trigger it.

Ah great, gnome-schedule sets this one to be able to get reproducible output from 'at' and 'crontab', whether it was set or not in the beginning is stored in a variable so it should be easy to unset it before running the shell.

- gaute

This should be fixed in commit b22840c (master). Marking as resolved fixed, thanks for tracking this down!

http://git.gnome.org/browse/gnome-schedule/commit/?id=b22840ca25f536697b3b411fa3f32bce46e36a22

- gaute