LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 02-20-2014, 04:49 PM   #1
user237
LQ Newbie
 
Registered: Feb 2014
Posts: 3

Rep: Reputation: Disabled
STDOUT redirect to empty variable is working for some users, but some have issues.


I have the following line of code in a shell script. Note that TFILE is not defined anywhere in the script. It's not even an environment variable and it's empty. This line of code is working fine for some users despite the fact that TFILE varaible is empty.

OUT_VALUE="$(/dev/bin/get.sh 2> ${TFILE})"

However, for some users it's throwing the below error.

"/dev/bin/load.sh[425]: : cannot open".

I am aware that the issue can be fixed by defining the TFILE variable value to some temp file(ex temp.log). But, we have this line of code in several scripts and it's not easy to fix all the scripts.

It seems some users are missing some Linux setting and getting the error. Any idea what Linux setting can fix this error?
 
Old 03-01-2014, 04:36 PM   #2
joe_2000
Member
 
Registered: Jul 2012
Location: Aachen, Germany
Distribution: Void, Debian
Posts: 823

Rep: Reputation: 237Reputation: 237Reputation: 237
How did you check that TFILE is indeed empty for the users who run the script successfully?
I'd suggest to add a line of debug output to the script
Code:
echo "Value of TFILE: $TFILE"
right above the problematic line and compare the difference between users.
If that does not help please post the complete script as well as scripts being called by the script. (e.g. /dev/bin/get.sh)
 
Old 03-02-2014, 09:33 AM   #3
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Debian
Posts: 8,576
Blog Entries: 31

Rep: Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195
Building on joe_2000's suggestion and in case TFILE has unusual characters, better do
Code:
printf '>%q<\n' "$TFILE"
 
Old 03-03-2014, 09:04 AM   #4
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,702

Rep: Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270
The error message refers to "/dev/bin/get.sh". Not stdout.

Normally such shell script would NOT exist in the /dev directory...
 
Old 03-04-2014, 08:43 AM   #5
catkin
LQ 5k Club
 
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Debian
Posts: 8,576
Blog Entries: 31

Rep: Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195Reputation: 1195
The error message refers to /dev/bin/load.sh ... ?
 
Old 03-04-2014, 10:10 AM   #6
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,702

Rep: Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270
Quote:
Originally Posted by catkin View Post
The error message refers to /dev/bin/load.sh ... ?
I think so. /dev is normally a devfs filesystem. It gets recreated on every boot. thus the file /dev/bin/load.sh wouldn't usually exist.

If the TFILE is null, you should be getting an "load.sh: line xxx: ${TFILE}: ambiguous redirect".

If it isn't null you should be getting no error whatsoever (the error is in the TFILE file).

If the ownership of the file identified by TFILE exists, but isn't allowed to be written to (or created) you get a "Permission denied" (same if the directory doesn't allow the file to be created) and you get a "No such file or directory" if directory doesn't exist.

suppose the value of TFILE is a space... well, you still don't get "cannot open".

So the only remaining thing for the message is "get.sh" which is reporting an error.

Now because we haven't seen the script that contains the questionable line, we don't know for a fact that the error being reported is even coming from WHERE it is being reported.

IF the location IS correct, then the message is being generated by a script programmed to emit something... and the only script in evidence at this time is get.sh.

If the location is INCORRECT, then it is more likely that the load.sh script is emitting the message itself, and possibly from using the TFILE parameter where it is (for some reason) null.

This could happen if TFILE happens to be defined in some environment that some users have and other do not.

One reason this is a possibility is that when the errors are generated, perror puts a space before and after the subject of the error (thus a null file name would get '/dev/bin/load.sh[425]: : cannot open' where the there are two spaces between the ":" characters). (looking at the code source for this page shows that IS the case with the message).

But identifying what it is that "cannot open" is tricky at that point. It is not a normal error message for the shell (different messages are used).
 
Old 04-03-2014, 11:06 AM   #7
user237
LQ Newbie
 
Registered: Feb 2014
Posts: 3

Original Poster
Rep: Reputation: Disabled
Just to clarify everyone..I tested the script like this..

1). Created a 0 byte script get.sh and placed it in /dev/bin directory.

2). Created a script called load.sh with just one statement shown below and placed it in /dev/bin directory

OUT_VALUE="$(/dev/bin/get.sh 2> ${TFILE})"

3). Executed the script load.sh and got the below error for some users and for some the script ran smoothly without producing any error.

"/dev/bin/load.sh[1]: : cannot open".

4). Just to make sure that the variable ${TFILE} doesn't exist anywhere in the OS, I tested the script multiple times by replaing the variable ${TFILE} with random strings like ${TFIXERERELRL}, ${REREREOR43434}, ${ERERERPeere434} etc. The results are same.

Now the mistery is how come some users are not getting any error? The error does make sence and is ideal behaviour, but why some users are not getting the error? We are facing this issue in AIX Box.

Thanks,
Lokesh.
 
Old 04-03-2014, 12:02 PM   #8
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,702

Rep: Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270Reputation: 1270
Some users may have defined the TFILE variable?
Perhaps it depends on their shell?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
STDOUT redirect to empty filename causing issues for some users. user237 Linux - Newbie 2 02-24-2014 05:27 AM
redirect AND print stdout samel_tvom Programming 12 10-07-2012 05:37 PM
[SOLVED] Permanently redirect stdout picho Linux - Newbie 6 02-17-2012 05:46 PM
How to redirect standard stdout to multi stdout ( Bash )? john.daker Programming 4 11-03-2008 11:20 PM
redirect stdout to a varible Furlinastis Programming 3 12-07-2005 06:01 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 03:42 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration