lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] [lmi-commits] odd/multiarch 768d4fc 4/7: Impede executing a sc


From: Greg Chicares
Subject: Re: [lmi] [lmi-commits] odd/multiarch 768d4fc 4/7: Impede executing a script that should instead be sourced
Date: Sun, 28 Apr 2019 11:18:00 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 2019-04-26 00:18, Vadim Zeitlin wrote:
> On Fri, 26 Apr 2019 00:04:17 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2019-04-25 22:13, Vadim Zeitlin wrote:
> GC> > On Thu, 25 Apr 2019 17:54:22 -0400 (EDT) Greg Chicares <address@hidden> 
> wrote:
> GC> [...]
> GC> > GC> +++ b/set_arch.sh
> GC> > GC> @@ -1,4 +1,4 @@
> GC> > GC> -#!/bin/sh
> GC> > GC> +#!/bin/sh this-script-must-be-sourced-not-run
> GC> > 
> GC> >  This is an interesting hack, but why do we need a hack at all here?
> GC> > Wouldn't it be better to just remove the shebang line completely and, 
> for
> GC> > good measure, make the file non-executable?
> GC> 
> GC> I considered those ideas and others presented here:
> GC>   
> https://unix.stackexchange.com/questions/424492/how-to-define-a-shell-script-to-be-sourced-not-run/424498
[...]
> GC> and a script with no shebang may be difficult for tools to recognize as
> GC> a script.
> 
>  I could see this for a script without .sh extension, but I'm pretty sure
> any tool would use the extension for recognizing the file type first.

$echo 'ls foo*' >eraseme.sh         
$shellcheck eraseme.sh              

In eraseme.sh line 1:
ls foo*
^-- SC2148: Tips depend on target shell and yours is unknown. Add a shebang.

> GC> Ingo's "Feb 16 '18 at 9:25" comment mentions vim detection as well. Do
> GC> you happen to know the magic setting to make vim detect 'GNUmakefile'
> GC> as a makefile?
> 
>  It should really be detected automatically, I checked Vim 7.2, which is
> the oldest version I still have immediate access to, and even it has the
> line
> 
>       au BufNewFile,BufRead *[mM]akefile,*.mk,*.mak,*.dsp setf make
> 
> in its filetype.vim. Something in your Vim configuration must be overriding
> this, but I don't know what. Please execute ":verbose set ft?" after
> opening this file to see where is this option set (and what is its value).
> 
>  You could also try adding
> 
>       au BufNewFile,BufRead GNUmakefile setf make
> 
> to your .vimrc, but I'd rather determine what prevents the default filetype
> detection from working.

For 'GNUmakefile', it actually does the right thing:

  filetype=make
        Last set from /usr/share/vim/vim81/filetype.vim line 935

and line 935 of '$VIMRUNTIME/filetype.vim':

" Makefile
au BufNewFile,BufRead *[mM]akefile,*.mk,*.mak,*.dsp setf make

exactly matches what you copied and pasted above.

The reason why that particular file is presented differently
than other makefiles becomes clear when I use that same command
for 'workhorse.make':

  filetype=conf
        Last set from /usr/share/vim/vim81/filetype.vim line 2150

" Generic configuration file. Use FALLBACK, it's just guessing!
au filetypedetect BufNewFile,BufRead,StdinReadPost *
        \ if !did_filetype() && expand("<amatch>") !~ g:ft_ignore_pat
        \    && (getline(1) =~ '^#' || getline(2) =~ '^#' || getline(3) =~ '^#'
        \       || getline(4) =~ '^#' || getline(5) =~ '^#') |
        \   setf FALLBACK conf |
        \ endif

After staring at line 935 repeatedly, I see that it matches
'*.mak' but not '*.make', so the solution is:
  au BufNewFile,BufRead *.make setf make

and now 'workhorse.make' is detected the same way as 'GNUmakefile':

  filetype=make
        Last set from ~/.vimrc line 37



reply via email to

[Prev in Thread] Current Thread [Next in Thread]