[SOLVED] Probably a silly problem: why sed is not working?

dedec0 · 04-15-2017, 12:16 PM

Probably a silly problem, but I cannot understand why sed is not working right now. A few lines from my Bash terminal should be enough to explain it:

Code:

$ cat input.txt 

lakjsdlsakj hello
dlakjdlsa hello ladksjladkjas
hello laskjdalskjdaslkdj
hello hello hello alksdja

$ sed 's/hello/world/g' input.txt

$

$ sed

$

$ whereis sed

sed: /bin/sed /usr/share/man/man1/sed.1.gz

$ alias |grep sed   # nothing there

$      sed 's/hello/world/g' input.txt

$ /bin/sed 's/hello/world/g' input.txt

lakjsdlsakj world
dlakjdlsa world ladksjladkjas
world laskjdalskjdaslkdj
world world world alksdja

$ # what can be wrong? :-/

$ # P.S.: I did not write the empty lines below this one

hydrurga · 04-15-2017, 12:35 PM

What does echo $PATH produce?

dedec0 · 04-15-2017, 01:19 PM

Quote:

Originally Posted by hydrurga

What does echo $PATH produce?

Code:

$ echo $PATH # output manually broken in a few lines
/home/me/bin:
/usr/local/sbin:
/usr/local/bin:
/usr/sbin:
/usr/bin:
/sbin:
/bin:
/usr/games:
/usr/local/bin/somethingIPutHere:
/home/me/bin/bin:
/media/DISK/novos/local/bin/

Nice! And now I have carefully checked that no folder before /bin has a file named sed.

There was one duplicate of /usr/local/bin... I never noted it before. Caused by a silly line in my .bashrc - fixed. It should not have had strange consequences, though - right?

Problem is still here...

astrogeek · 04-15-2017, 02:39 PM

What does...

Code:

which sed
ls -l /bin/sed

...say?

ondoho · 04-15-2017, 02:47 PM

Code:

which sed

edit:
astrogeek was quicker.

dedec0 · 04-15-2017, 03:42 PM

Quote:

Originally Posted by astrogeek

What does...

Code:

which sed
ls -l /bin/sed

...say?

I did not know about 'which'! I just imagined that something like that should exist... hehe (:

It says what I expected (expected even more after I checked each folder I have in my $PATH). But the output is still wrong - it just exits when called without the full path.

Here it goes, with a few more tests:

Code:

$ sed

$ which sed

/bin/sed


$ sed

$ /bin/sed   # Called this way, same no arguments, outputs help! :-/

Uso: /bin/sed [OPÇÃO]... {script-apenas-se-for-único} [arquivo-entrada]...

  -n, --quiet, --silent
                 suprime a impressão automática do buffer padrão
 [... output edited ...]

Página do GNU sed : <http://www.gnu.org/software/sed/>.
Usando ajuda geral do software GNU: <http://www.gnu.org/gethelp/>.

$ ls -l /bin/sed   # my ls has a few "human friendly" changes

56K -rwxr-xr-x 1 root root 55K 2009-12-21 20:43 /bin/sed

$ 'ls' -l /bin/sed 

-rwxr-xr-x 1 root root 55364 2009-12-21 20:43 /bin/sed

hydrurga · 04-15-2017, 03:50 PM

Are there any references to sed in your ~/.bashrc?

dedec0 · 04-15-2017, 04:35 PM

Quote:

Originally Posted by hydrurga

Are there any references to sed in your ~/.bashrc?

Yes, there was a function named sed there! :-/

Code:

# this was to show disk free space (it is shown here just because it calls sed a few times)
alias livre='echo -n `... | ... |sed "s/.../\1 /"`; ... ; echo -n `... |sed "s/...//"` ; echo -n ...

# The culprit:

# Function to make it unnecessary to give files to sed because that is painful
# Função pra não ter que dar arquivos pro sed porque é chato
function sed()
{
    #echo 'sed SEU-BLABLABLA / d e v / s t din VAI /d e v / s tdout'
    if (( $# < 1)); then
	return
    fi
    #    sed "$1" / d e v /s t d i n
}

This is something I abandoned in my bashrc many months ago. I do not remember what I did - I may have even discarded the idea, but something nasty (for me! LOL) was forgotten in this file...

The commands 'which' and 'whereis' should not be aware of shell functions? I did not imagine they would miss that, expected the opposite! Didn't you too?

For new shells, it will be working now. For current shells I need to run

Code:

$ unset sed

to fix it.

Thank you for your attention! ^,^

hydrurga · 04-15-2017, 05:05 PM

Glad you found the problem.

No, I wouldn't have expected either which or whereis to also search for user-defined shell functions, perhaps due to the added complexity that would be required. They're both pretty basic commands.

Anyway, onwards and upwards. If you consider the thread solved then you can mark it so using "Thread Tools" at the top of the thread.

astrogeek · 04-15-2017, 05:10 PM

The next suggestion I had in mind was to run with full path....

Code:

$ /bin/sed 's/hello/world/g' input.txt

If that worked then you would know something else was running as sed.

But thanks to hydrurga you jumped right to the problem!

dedec0 · 04-15-2017, 05:45 PM

@hydrurga I really expected them to check defined functions. And I think it is not complex - could it be provided by Bash? Maybe someone can craft a "whatisthis" function to do that.

@astrogeek You should have noted that I ran sed with full path a few times, comparing with the different behaviour of the "normal" sed call.

I was just waiting for a comment about the expectations I had (and have) about 'whereis' and 'which'. Now the thread is solved, but I won't mind discussing things a bit more, if anyone does.

Thank you again

astrogeek · 04-15-2017, 05:48 PM

Quote:

Originally Posted by dedec0

@astrogeek You should have noted that I ran sed with full path a few times, comparing with the different behaviour of the "normal" sed call.

So you did! My glasses must have been smudged... my memory faded between posts... my dog ate my homework...

hydrurga · 04-15-2017, 06:06 PM

Quote:

Originally Posted by dedec0

And I think it is not complex - could it be provided by Bash?

Yes, but for a start, Bash isn't the only shell out there.

Whereis and Which simply search specific paths for specific filenames. To search for user-defined shell functions, you would have to start parsing shell-dependent start-up scripts in all the different filesystem locations that those scripts can exist, and parsing all the different forms/syntax that the functions can be written in. It could very quickly become unwieldy and unsustainable.

norobro · 04-15-2017, 10:34 PM

Better late than never????

declare or typeset would have listed that function. From the bash man page:

Quote:

...
The -f option will restrict the display to shell functions. The -F option inhibits the dis‐
play of function definitions; only the function name and attributes are printed.
...

dedec0 · 04-16-2017, 08:54 AM

Quote:

Originally Posted by norobro

Better late than never????

declare or typeset would have listed that function. From the bash man page:

Nice!

To make this post I have read the manual pages of 'whereis' and 'which' for the first time. And (of course) Bash's too, but I have read it many many times before! :D

What would people think if we build a shell function to check the kind of what happens when we type a given command? It should test:

1. If it is a defined alias (kind = alias)

Code:

# Like:
$ alias |grep sed

# ...

2. If it is an already defined shell function (declare/typeset is present in other shells?) (kind = function)

Code:

# Like:
$ declare -F | grep sed

declare -f __git_aliased_command
declare -f sed

3. If it is defined in any (and all) paths in current $PATH variable (is this exactly what 'which' does, except that it does not follow symbolic links? Why? Can this fact be a reason to make a replacement to 'which', as it seems to me?) (kind = executable file)

4. (not) Searching predefined common paths that are not necessarily in the current $PATH is not wanted. This is exactly what 'whereis' does, right? (kind would be something outside the current environment, not needed in my use case)