Yes I read an answer that Zanna had given and it got piqued

bani.com.br/2007/01/sudo-insults

I peeked into the /etc/sudoers file using gedit and the file states it must be edited with vi, I tried that but I am not a good vi user so I ejected the terminal

Oh, you don't have to use vi.

What do you mean when you say you ejected the terminal?

well "q" enter didn't work so i clicke the X to close the terminal

haha well I don't feel bad

Yeah, to quit vi or vim, you make sure you're in normal mode (by pressing Escape, which puts you in it if you're not) and then press :q or, if you want to quit even with unsaved changes, :q!.

More details in the linked question.

So anyway, you can use any editor with the visudo command.

Is Gedit currently running? If so, exit it.

Then run:

listening

sudo visudo /etc/sudoers

Well that will probably not use Gedit.

Run:

sudo -H VISUAL=gedit visudo

sudoers/tmp opened now I insert the defaults Insults just after the first set of comments?

visudo automatically edits /etc/sudoers when you don't give it a filename so you don't have to specify that.

@xtrchessreal It's normal that it's a tmp file. visudo will check your syntax when you quit the editor and write it to the file if it's changed and correct syntax.

It should have the same capitalization as the other Defaults lines.

So, for example, I have:

Defaults    env_reset
Defaults    mail_badpass
Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

I would put:

Defaults    insults

The spacing isn't really important, though I suggest using the same spacing as the other lines for readability. But the first letter of Defaults has to be capitalized and insults has to not be capitalized.

I suggest putting the new Defaults line immediately after the last one already present.

okay after the last one already present

After you save the file and quit the text editor, visudo should attempt to write the temporary file to /etc/sudoers.

okay let me hit save

cool working now...Thanks

called me doofus

Congratulations! :)

Thanks I've been wanting to be insulted for a few hours...

You're welcome.

Since this conversation is off-topic, I'm going to move it over to the Island of castaway thoughts, which was created to hold -- and allow to be continued -- the many off-topic conversations that arise here in the Downboat.

← 41 messages moved from Raiders of the Lost Downboat‌​

@xtrchessreal Welcome to the island!

The island yes

thank

s

Certainly.

You are always welcome on the island.

And in the downboat.

And in the general room.

Also in every room, except rooms that don't let you in, like the room for only SE moderators.

Unless you are an SE moderator. Then you're welcome there too.

:)

Its much better than FB or news blogs

I've gotta run, dinner time here in CO

Haha I always turn the insults on. Otherwise mistyping my password irritates me a little. With insults on, I get a choice of success or amusement

@EliahKagan you got around to it quickly I would say... I hope you are closer to figuring out how to edit your answer

@EliahKagan yeah, that's probably what we want

@Zanna Well the other thing is, all the stuff in /etc/skel/.bashrc is stuff you definitely want in interactive login shells if you want it in interactive non-login shells.

There are no commands before the interactivity check.

Then it disables recording of duplicate lines and lines that start with a space in the command history, makes it so that the history file will be appended rather than overwritten, sets how many lines should be stored in the history and in the history file, makes the shell update LINES and COLUMNS automatically whenever hte terminal window is resized between commands (this works over SSH and is immensely convenient in such login shells), makes less display some files more prettily...

...does a whole bunch of stuff to set up the prompt (all of which is equally applicable in login and non-login shells, with the arguably exception of showing information about being in a chroot, which I can argue is either more or less important for a login shell), sets a title bar if the terminal supports it (which works over SSH), sets up colorization for ls, defines ls and grep related aliases, causes aliases in ~/.bash_aliases to be defined...

...and enables command-specific tab completions.

I have skipped the stuff that is present but commented out, like enabling globstar, which is sort of an extreme case of something one wouldn't likely want to depend on whether or not one were in a login shell. Imagine expecting it to be off because you're in a login shell and not worrying about a spurious second *, but it turns out you typed bash to change PS1 to paste text into an AU answer.

haha something could break

@Zanna I want to link to files like /etc/skel/.profile online. Back when Launchpad had complete source code on Bazaar, this was easy. Is there a way to do it now?

hmm

It occurs to me that this might not be as valuable as I had thought.

/etc/profile sources files in /etc/profile.d/.

But in 14.04, the file in the source package doesn't include that.

But /etc/profile on 12.04 sourced it (that's what I checked when I wrote that answer), and it sources it on my 16.04 system.

Although, that system was upgraded from earlier releases and maybe I have an old file.

@Zanna Which release did you install with? Can you check your /etc/profile to see if it contains this?

if [ -d /etc/profile.d ]; then
  for i in /etc/profile.d/*.sh; do
    if [ -r $i ]; then
      . $i
    fi
  done
  unset i
fi

yes, it contains exactly those lines right at the end. I installed 17.04 (erasing the disk and overwriting the partitions)

Thanks.

any time :)

Btw please feel free to ignore any of these messages, even if I ping. Your help has already been substantial; please don't feel obligated to continue if it's not a good time or whatnot.

Also... isn't it bad that they don't quote $i?

What if a file in /etc/profile.d/ has spaces in its name?

it seems very bad, since the user might have placed my global env config file there

lol

Well that wouldn't be a problem, because it doesn't end in .sh.

@EliahKagan :)

But if it did... Maybe their goal us to run a separate my file with env, config, and file as command-line arguments.

Actually, what is the behavior of the . and source builtins when arguments are passed to the filename?

hahaha

I mean, it's not a script that is being run.

It bothers me that I do not know this.

how can we test this? :)

Yes. Easily. I just did.

Sorry, I thought you had just said "can."

ek@Io:~/source$ echo "$1"

ek@Io:~/source$ cat 1.sh
echo "$1"
ek@Io:~/source$ . ./1.sh

ek@Io:~/source$ . ./1.sh foo
foo
ek@Io:~/source$ echo "$1"

ek@Io:~/source$

oh nice!

So the positional parameters are set for the file being sourced but not for the caller, which is what one would want. It's like with a shell function. Except the local builtin is still not allowed to be used:

ek@Io:~/source$ cat local.sh
local x="$1"
echo "$x"
ek@Io:~/source$ . ./local.sh bar
bash: local: can only be used in a function

ek@Io:~/source$

this is really good to know

dash doesn't support positional parameters for sources files, though:

ek@Io:~/source$ dash
$ echo "$1"

$ . ./1.sh

$ . ./1.sh foo

$ echo "$1"

$

But bash still supports it in POSIX mode:

ek@Io:~/source$ bash --posix
bash-4.3$ echo "$1"

bash-4.3$ . ./1.sh

bash-4.3$ . ./1.sh foo
foo
bash-4.3$ echo "$1"

bash-4.3$

ah! this is ringing a bell... I suspect I have an answer somewhere I need to expand

@Zanna An answer you say?

That sounds like the sort of thing that ought to be encouraged on this site.

Feel free to use this:

ek@Io:~/source$ unset foo; for shell in bash 'bash --posix' dash 'busybox sh' zsh ksh93 mksh lksh posh yash /opt/schily/bin/{,bo}sh; do (set -x; $shell -c '. ./1.sh foo; echo "$foo"'); done
+ bash -c '. ./1.sh foo; echo "$foo"'
foo

+ bash --posix -c '. ./1.sh foo; echo "$foo"'
foo

+ dash -c '. ./1.sh foo; echo "$foo"'


+ busybox sh -c '. ./1.sh foo; echo "$foo"'
foo

+ zsh -c '. ./1.sh foo; echo "$foo"'
foo

+ ksh93 -c '. ./1.sh foo; echo "$foo"'
foo

+ mksh -c '. ./1.sh foo; echo "$foo"'
foo

Preferably without the unset foo which is pointless.

In the patched bash-4.3 source folder that I obtained by running apt source bash on my 16.04 system, debian/etc.profile doesn't have a command to source files from /etc/profile.d/ either. To rule out the possibility that it was taken out for just some releases -- though I think that's not the explanation -- would you be willing to run apt source bash on your 17.04 system (somewhere that you're willing to have several files and a directory of numerous other files be created) and check?

@EliahKagan thanks!

zanna@toaster:~/playground/bash-4.4/debian$ cat etc.profile
# /etc/profile: system-wide .profile file for the Bourne shell (sh(1))
# and Bourne compatible shells (bash(1), ksh(1), ash(1), ...).

PATH="/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games"

if [ -f /etc/debian_chroot ]; then
  debian_chroot=$(cat /etc/debian_chroot)
fi

if [ "$PS1" ]; then
  if [ "$BASH" ]; then
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
    if [ -f /etc/bash.bashrc ]; then
        . /etc/bash.bashrc

@Zanna Can I see your full /etc/profile as well?

$ cat /etc/profile
# /etc/profile: system-wide .profile file for the Bourne shell (sh(1))
# and Bourne compatible shells (bash(1), ksh(1), ash(1), ...).

if [ "${PS1-}" ]; then
  if [ "${BASH-}" ] && [ "$BASH" != "/bin/sh" ]; then
    # The file bash.bashrc already sets the default PS1.
    # PS1='\h:\w\$ '
    if [ -f /etc/bash.bashrc ]; then
      . /etc/bash.bashrc
    fi
  else
    if [ "`id -u`" -eq 0 ]; then
      PS1='# '
    else
      PS1='$ '
    fi
  fi
fi

if [ -d /etc/profile.d ]; then