Member Avatar for leghorn

hi all

only the weirdest thing happened with me just now. I was debugging a shell script and I found that a step that was supposed to execute later ws getting executed prior to another step for no reason. You know any ?

i mean have a look at the following command-
[if $DISPLAY xstatus | $GREP "$right...$right" ]

here it tries to grep first(and hence gives an ambiguous output) and later displays the xstatus.(It should do the opposite,right?)

also any idea what the command which frsh does ? it gives no output on my system. But it sure does something.

Your valuable inputs are always welcome

~cheers

  • 2 Contributors
  • 5 Replies
  • 130 Views
  • 2 Hours Discussion Span
  • Latest Post Latest Post by Watael

Dani AI

Generated

Two likely, separate issues are being mixed in the thread: a parsing/syntax problem and normal pipeline semantics. was right to question the square‑bracket usage — [ is the test builtin and misplacing it will change how the shell parses the whole line. At the same time, pipelines start both ends nearly simultaneously, so the reader (grep) can appear to “run first” because it starts and waits on input while the producer writes; that is normal and not a strict sequential ordering.

Checklist to diagnose what actually happened:

  • Confirm which shell the script runs under (sh/bash vs csh/tcsh). csh-family shells have different parsing and give “ambiguous” messages for certain expansions and redirects.
  • Print the literal contents of the variables used (for example the DISPLAY value) to ensure they expand to what you expect and do not inject tokens that become commands or redirections.
  • Verify whether any names are aliases, shell functions, or builtins (use the shell’s builtin lookup, e.g. command -v frsh or type -a frsh) — which behaves inconsistently across environments.
  • Check the pattern you give to grep: unescaped metacharacters or unintended shell expansions can change matches or produce confusing output.

Practical fixes and safeguards:

  • Fix the conditional syntax so the shell parses an if-statement (don’t wrap that conditional in [ unless you actually mean test expressions).
  • Escape or quote regex metacharacters, or use fixed-string mode if you want literal dots.
  • In bash, enable pipefail if you need the pipeline to fail when any stage fails; otherwise the exit status is that of the last command.
  • If strict ordering of output is required, capture the producer output to a temporary file or use the shell’s process-substitution features rather than relying on perceived ordering from a pipe.

These checks separate parsing bugs from normal concurrent behavior and will reveal whether the surprising order came from malformed syntax, an unexpected shell, or simply the way Unix pipelines behave.

Recommended Answers

All 5 Replies

Member Avatar for Watael

hi,

[ is an alias for test, it's useless here.

try this way:

if $DISPLAY xstatus | grep "$right...$right"
then echo ok
else echo ko
fi

and man which to know what does which frsh

Member Avatar for leghorn

hi

thanks for the reply.
if $DISPLAY xstatus | grep "$right...$right" also gives the same problem
any ideas ? :/

~cheers

Member Avatar for Watael

what does xstatus' print? and what should grep keep of it?

Member Avatar for leghorn

status of some policy(thats a definite output,no issues there) .. and grep searches the value 11...12

Member Avatar for Watael

again what does xstatus print?
how am I supposed to find what's wrong without any input?

from my crystal ball:

xstatus | grep '11\.\.\.12'

or

DISPLAY=$DISPLAY xstatus | grep '11\.\.\.12'

though DISPLAY=$DISPLAY doesn't make much sense :(

then we'll try to find out what you want if to do.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.