Bash: task: command not found error

Hey there,

Having a curious occurence, not an issue per say but I need help to figure it out

Every time I open a new terminal instance, this error is printed to the terminal:

bash: task: command not found

From my own digging around, I though it might have to do with my .bashrc since I added some functions and aliases, but I have removed all of that and also followed this to reset my .bashrc:

your `.bashrc` might be broken, `cp /etc/skel/.bashrc ~/.bashrc` and if you have a `.bashrc.d` folder in your $HOME rename that temporarily so you can figure out where it breaks - Universal Blue

However the error message persists… any ideas where to go from here?

More research indicates it may be related to the order of the linuxbrew directories in my PATH but im not sure what to do about that

I wish I was better at figuring this out on my own but im not there quite yet, I have been using linux for years (dual booting mint most of that time, but this year ive been trying to main linux in the form of Aurora) and im not a total noob, but im not super experienced with universal blue yet

Any help is much appreciated

Some good, old-fashioned printf debugging might help. :sweat_smile:

echo ‘Hello from profile!’ >> ~/.bash_profile, for example. Maybe a few “echo KILROY WAS HERE 1/2/3” things at various interesting spots around places where your files are sourcing other files. If you’re really stumped, you can try creating a new user to test with or run diffs against. Or maybe test logging in via a virtual console or an ssh shell… if you’re running inside, say, vscode then it seems very sensible to try not running inside vscode.

You could also brew shellcheck - it might already even be installed by default: whereis shellcheck || brew install shellcheck; shellcheck -s bash ~/.bashrc Though trying to navigate its rather terse verbiage may just exacerbate your frustration.

Ooof I just remembered I installed taskwarrior a while back, the binary name for which is task

Taskwarrior was installed with linuxbrew, is that why it cant be found by bash at first? Taskwarrior is working fine and responding to task so im still at a bit of a loss

Furthermore, that doesnt explain why task is being called every time I open up the terminal…

Is there a conflict I dont know about regarding task?

I ran shellcheck -s bash ~/.bashrc like you said but there doesnt seem to be any problems there. Theres certainly no mention of task and

Im not sure what appending random text to .bashrc or .bash_profile would accomplish, could you explain your line of reasoning here?

I dont know what you mean by interesting spots/places my files are sourcing other files… im unfamiliar with shell customization

I guess you could mean look into any other files/directories that are referenced in my .bashrc and .bash_profile now that I write this out… is that what you were saying?

Would I be looking for any mention of task in those other locations?

It’s what I joked about via printf debugs:

You have a situation where you do not understand the flow of control through your own shell scripts and the suggestion to echo random (but unique) tidbits would hopefully help you understand.

If it were me and I saw the error about being unable to find a command named task echo to the shell AFTER “Kilroy was here! 1” but BEFORE “hello from .profile!”, for example, I would know that the erroneous bit of script lied somewhere in my .bashrc file or something sourced therein. You can adjust the location of the echo statements until you squeeze the scope so small that the bug just can’t hide. Does that help?

It’s very common for one shell script to invoke another one. At the top of your .bashrc, for example, you probably see something like . /etc/bashrc That’s executing /etc/bashrc everytime you open a shell.

Yep.

Did you also try opening your shell from different places? Using a different terminal, for example? Did you try creating a new user just to see if it was a system-wide error?

I suppose you could also make a dummy alias or executable to handle the call. You might even discover something by looking at the command-line arguments. Try:
#!/usr/bin/perl
print “$0 = $0\n”;
print “$#ARGV = $#ARGV\n”;
print “@ARGV = @ARGV\n”;
pasted into a file named task and made executable’. It might even be possible to examine the stack to determine where the flow of execution will return… though that seems like a lot of effort.

gl